> I would like to change the IP address (netmask, gateway etc.) of an Interface
> (eg. fxp0) from within my C source code.
>
> 1. Is this possible to do without the SIOC ioctl call? (i am already in the
> kernel).
Make the call from within the kernel.
> 2. Which structure and which member should
>
> I've come up empty-handed hunting for a constant that defines the
> maximum UID supported by the system. I'm working on our passwd and
> pwd_mkdb stuff and want to get rid of the artificial limitation of 65535
> (USHRT_MAX) imposed in (at least) pwd_mkdb.
>
> Have I missed a useful define, or
> I'l looking at defining about a dozen ioctl calls for a local device driver.
> When looking at the _IO, _IO, _IOW, _IOR, and _IOWR macros, I'm interested if
> there are any "reserved" or "local" values for the first parameter?
Not really, as such.
> In short, I'd hate to use a seemly unused
On Thu, 29 Jul 1999, Martin Cracauer wrote:
> In
> ,
> Rayson Ho wrote:
> > Hi,
> >
> > I am not sure whether this is known to this list or
> > not, but here is the URL for ordering:
> >
> > http://www.bsdi.com/products/evalcd/
>
> The thing that gets my attention is the gdb with threads su
Mike Smith wrote:
> > I would like to change the IP address (netmask, gateway etc.) of an
> > Interface
> > (eg. fxp0) from within my C source code.
> >
> > 1. Is this possible to do without the SIOC ioctl call? (i am already in the
> > kernel).
>
> Make the call from within the kernel.
But I wa
> Mike Smith wrote:
>
> > > I would like to change the IP address (netmask, gateway etc.) of an
> > > Interface
> > > (eg. fxp0) from within my C source code.
> > >
> > > 1. Is this possible to do without the SIOC ioctl call? (i am already in
> > > the
> > > kernel).
> >
> > Make the call from w
hi, there!
On Mon, 26 Jul 1999, Steven Fletcher wrote:
> I've seen the PAM modules/libraries/etc for MySQL and noticed that the
> FTPD Makefile has a Kerberos PAM option, and was wondering if anyone
> knows of a way to get FTPd talking to MySQL... or if it would work at
> all?
ftpd PAM patches (
Sorry I know i should not mail to the mailinglist. But I can not unsubscribe
Please help me
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
w...@softweyr.com (Wes Peters) writes:
> [ENOBUFS] Insufficient system buffer space exists to complete the op-
>eration.
Do you know what kind of circumstances that error *really* occurs
under?
If it happened with files, that would be a bug and should be fixed.
The
On Fri, 30 Jul 1999 00:53:56 MST, Mike Smith wrote:
> It probably belongs in param.h, and you can probably safely calculate it
> as (uid_t)0 - 1;
Excellent.
Another question I should have asked in my original mail is this: are
there magical reasons why we should want pwd_mkdb to bleat for ever
Hi!
As I promised earlier, here is some information how to
integrate KAME and PAO into the FreeBSD 3.2-RELEASE
source tree.
The current status is:
- FreeBSD+KAME
- no conflicts during merge
- "make world" is working
- systems are up and running without any problems :-)
- FreeBSD+PAO
>PS. Should we setup a cvsup server somewhere (not in the USA) which would
>have these branches? KAME people, what do you say of having such a
>service in one of your servers?
guys at imasy.or.jp has been doing it for FreeBSD228+KAME+PAO for a
while, so please feel free to
Tim Vanderhoek writes:
> I do. Still far too slow. I'll work on this tomorrow, since that
> seems the only way to convince people that mmap is not such a big
> win. :-(
mmap() gives a fourfold speed increase. I call that a big win.
I have a few other ideas which will make 0.11 even faster.
D
James Howard writes:
> DES tells me he has a new version (0.10) which mmap()s. It supposedly
> cuts the run time down significantly, I do not have the numbers in front
> of me. Unfortunetly he has not posted this version yet so I cannot
> download it and run it myself.
It's in the usual place (
John-Mark Gurney writes:
> it was VERY simple to do... and attached is the patch... this uses the
> option REG_STARTEND to do what the copy was trying to do... all of the
> code to use REG_STARTEND was already there, it just needed to be enabled..
Funnily, I experience a near-doubling of running
Dag-Erling Smorgrav writes:
> John-Mark Gurney writes:
> > it was VERY simple to do... and attached is the patch... this uses the
> > option REG_STARTEND to do what the copy was trying to do... all of the
> > code to use REG_STARTEND was already there, it just needed to be enabled..
> Funnily, I
Sheldon Hearn writes:
> Another question I should have asked in my original mail is this: are
> there magical reasons why we should want pwd_mkdb to bleat for every
> encountered UID greater that 65535 ?
How many times do I have to go through this?
There is no "artificial limitation in pwd_mkdb"
On 30 Jul 1999 15:38:30 +0200, Dag-Erling Smorgrav wrote:
> How many times do I have to go through this?
Until I stuff a comment in the source that explains this. :-)
> There is no "artificial limitation in pwd_mkdb". pwd_mkdb warns
> against UIDs larger than 65535 because legacy software that
Sheldon Hearn writes:
> Would you be happy with changing things so that only one warning is
> generated? Something like "9 > max_uid 65535: others may exist"? The
> current behaviour is quite annoying with large passwd files. :-)
Sure, and maybe modify the warning to say something like "legac
John-Mark Gurney wrote:
>
> ok, I just made a patch to eliminate the copy that was happening in
> procfile, and it sped up a grep of a 5meg termcap from about 2.9sec
> down to .6 seconds... this includes time spent profiling the program..
> GNU grep w/o profiling only takes .15sec so we ARE gettin
Tim Vanderhoek wrote:
>
> I'm sorry. I've read your message and have decided that you're wrong.
Not that you did bother to counter the points I made. You only
comment on the one thing I said was probably insignificant. Are you
taking your clues from me? :-)
> Outside of the regexp library, algo
ftp://ftp.ofug.org/pub/grep/grep-0.11.tar.gz
More (gprof-assisted) speedups.
DES
--
Dag-Erling Smorgrav - d...@yes.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Dag-Erling Smorgrav wrote:
>
> To be precise, I experience a 30% decrease in system time and a 100%
> increase in user time when I use RE_STARTEND and eliminate the
> malloc() / memcpy() calls in procfile().
Could you please test my patch that removes malloc() but bot
memcpy()? Here it is again,
"Daniel C. Sobral" writes:
> Dag-Erling Smorgrav wrote:
> > To be precise, I experience a 30% decrease in system time and a 100%
> > increase in user time when I use RE_STARTEND and eliminate the
> > malloc() / memcpy() calls in procfile().
> Could you please test my patch that removes malloc() bu
"Daniel C. Sobral" writes:
> Could you please test my patch that removes malloc() but bot
> memcpy()? Here it is again, though against an old version:
Bingo. REG_STARTEND is significantly more expensive than memcpy().
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send ma
Ville-Pertti Keinonen wrote:
>
> w...@softweyr.com (Wes Peters) writes:
>
> > [ENOBUFS] Insufficient system buffer space exists to complete the
> > op-
> >eration.
>
> Do you know what kind of circumstances that error *really* occurs
> under?
>
> If it happened wit
>
>
> On Fri, 30 Jul 1999 00:53:56 MST, Mike Smith wrote:
>
> > It probably belongs in param.h, and you can probably safely calculate it
> > as (uid_t)0 - 1;
>
> Excellent.
>
> Another question I should have asked in my original mail is this: are
> there magical reasons why we should want pwd_
:w...@softweyr.com (Wes Peters) writes:
:
:> [ENOBUFS] Insufficient system buffer space exists to complete the
op-
:>eration.
:
:Do you know what kind of circumstances that error *really* occurs
:under?
:
:If it happened with files, that would be a bug and should be f
:Your new "behavior" flag isn't known by vm_map_simply_entry, so
:map simplification could drop the behavior setting on the floor.
:I would prefer that the behavior is folded into eflags.
:
:Overall, I agree with the direction. Behavior is correctly a map
:attribute rather than an object attribut
Daniel C. Sobral scribbled this message on Jul 30:
> Dag-Erling Smorgrav wrote:
> >
> > To be precise, I experience a 30% decrease in system time and a 100%
> > increase in user time when I use RE_STARTEND and eliminate the
> > malloc() / memcpy() calls in procfile().
>
> Could you please test my
I'm looking at booting(embedded devices) and I've been looking at lilo boot
loader code and booteasy bootloader code...
does anyone know of any documentation that anyone out there has done on this
topic? -- more specifically without
bios calls/support?
I've seen the booteasy code at:
ftp://ftp.f
On Fri, Jul 30, 1999 at 09:51:35AM -0700, Matthew Dillon wrote:
>
> I'm not sure I see how MADV_FREE could slow performance down unless,
> perhaps, it is the overhead of the system call itself. e.g. if malloc
> is calling it on a page-by-page basis and not implementing any hysteresis.
:In any case, the man page for malloc/free explains how to change
:the default, if you're a part of the "oppressed" 1%.
:
:Alan
Not with a gig of memory :-). My only concern is for the performance
curve to look good and not be too jagged.
-Matt
Hi folks,
We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
Does anyone feel up to writing one?
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the links.
-- Tom Christia
-hackers,
Is the FreeBSD Device Driver Writers Guide at
http://www.freebsd.org/tutorials/ddwg/ddwg.html
still correct? I know there have been changes to this area of the tree
over the past 6 months or so, but I don't know how much of that document
is still appropriate for what we have now.
We got off onto a big tangent about switches and vlans and stuff and I
learned a number of interesting things, don't get me wrong, but we
still haven't established any consensus on the trade-offs of enabling
bpf. This wasn't meant to be a hypothetical discussion, I'm truly
trying to measure the tr
On Thu, Jul 29, 1999 at 10:45:51AM -0500, Alton, Matthew wrote:
> I ran screaming into the woods last year from trying to grok VOP_foo. The
> prospect of a rewrite fills me with warmth and fuzziness. I hereby volunteer
> to maintain the VOP(9) man pages and to flesh out my notes into a big, beefy
On Fri, Jul 30, 1999 at 09:13:52AM -0700, a little birdie told me
that Mike Smith remarked
>
> I think that the administrator should be forced to override the warning
> manually to indicate that they are aware of the issues they are getting
> themselves in for, or at the very least that there sh
Here is a pro vote for enabling BPF in GENERIC:
It will let us use a dhcp client in the install programs, this is of tremendous
use to many people as DHCP starts to become much more popular. I cannot
net install a machine at home since that is on a DHCP cable modem service.
Also, if root is comp
Time for this oppressed person to go ln -s H /etc/malloc.conf...
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___
If root is compromised, that's the only way bpf can be gotten to by
default. When root's compromised, if no bpf is available, the mem devices
can still be created (if not there) and network queues can be listened to.
And can't IFF_PROMISC be turned on too?
There's no good reason to not have bpf in
> It will let us use a dhcp client in the install programs, this is of
> tremendous use to many people as DHCP starts to become much more
> popular. I cannot net install a machine at home since that is on a
> DHCP cable modem service.
Well, just to clarify this, if you're installing a 4.0 snapsho
> There's no good reason to not have bpf in at least the boot disk kernel.
It already is. That's not the question under discussion here - we're
talking about how to make things work in the post-installation boot
scenario.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubs
On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
> > There's no good reason to not have bpf in at least the boot disk kernel.
>
> It already is. That's not the question under discussion here - we're
> talking about how to make things work in the post-installation boot
> scenario.
When did that hap
On Fri, 30 Jul 1999, Brian F. Feldman wrote:
> On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
>
> > > There's no good reason to not have bpf in at least the boot disk kernel.
> >
> > It already is. That's not the question under discussion here - we're
> > talking about how to make things work in
: But even if you turn off the bpf device, you still have /dev/mem and
: /dev/kmem to worry about. For that matter, the intruder can still write
: raw devices. Also, there is another kernel feature called kldload(8).
BTW, I wrote this section because a hacker actually installed t
On Fri, 30 Jul 1999, Matthew Dillon wrote:
> : But even if you turn off the bpf device, you still have /dev/mem and
> : /dev/kmem to worry about. For that matter, the intruder can still write
> : raw devices. Also, there is another kernel feature called kldload(8).
>
> BTW, I wr
> : But even if you turn off the bpf device, you still have /dev/mem and
> : /dev/kmem to worry about. For that matter, the intruder can still write
> : raw devices. Also, there is another kernel feature called kldload(8).
>
> BTW, I wrote this section because a hacker actually i
> This is a clear security vs functionality issue and I need to get a
> good feel for which "cause" is ascendent here in knowing which way to
> jump on the matter. Can we now hear the closing arguments from the
> pro and con folks?
I thought we decided that the networking gurus we're going to mak
:> BTW, I wrote this section because a hacker actually installed the bpf
:> device via the module loader during one of the root compromises at BEST,
:> a year or two ago. He had gotten it from a hackers cookbook of exploits
:> which he convieniently left on-disk long enough for ou
Anyone have detailed docs for 3Com's 3C515 NIC? I found
Guy Helmer's driver, http://www.freebsd.org/~ghelmer/3c515/
but it didn't recognize the card I have. I was going to
spend some time this weekend to see if I could figure out
what was up. Just thought it might be easier if I had
a little lig
On Fri, 30 Jul 1999, Nate Williams wrote:
> > This is a clear security vs functionality issue and I need to get a
> > good feel for which "cause" is ascendent here in knowing which way to
> > jump on the matter. Can we now hear the closing arguments from the
> > pro and con folks?
>
> I thought
> I thought we decided that the networking gurus we're going to make it
> possible to send out broadcast packets on an unconfigured interface so
> that DHCP would work, so that bpf wasn't required.
I believe we decided that this would be the preferred method, yes. I
don't think, however, that we
On Fri, 30 Jul 1999, Steve Price wrote:
> Anyone have detailed docs for 3Com's 3C515 NIC? I found
> Guy Helmer's driver, http://www.freebsd.org/~ghelmer/3c515/
> but it didn't recognize the card I have. I was going to
> spend some time this weekend to see if I could figure out
> what was up. Ju
I prefer to work in flat ASCII. Perhaps the doc project can HTMLize
the final product.
Currently, I'm hatching a plan to free up an AMD386/40 running
FreeBSD 2.1.5 for use as a 4.x sandbox. The little thing has been
faithfully and unerringly natd-ing my whole Solaris/NetBSD/Linux/
UNIXWare LAN o
* Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]:
> Hi folks,
>
> We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
>
> Does anyone feel up to writing one?
Saw it before, noticed it, placed on my to-do list. If no-one objects
I'll submit a manpage per a.out(5) sty
* Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]:
> -hackers,
>
> Is the FreeBSD Device Driver Writers Guide at
>
> http://www.freebsd.org/tutorials/ddwg/ddwg.html
>
> still correct? I know there have been changes to this area of the tree
> over the past 6 months or so, but
On Wed, 28 Jul 1999, Matthew Dillon wrote:
> :> Sheldon Hearn writes:
> :> > I plan to mention in the comments for each service in /etc/services, the
> :> > latest RFC describing the service.
> :>
> :> Good idea.
> :
> : H... I'm not sure what this gets us. Wouldn't it be better to
> :pl
On Thu, 29 Jul 1999, Ben Rosengart wrote:
> On Thu, 29 Jul 1999, Josef Karthauser wrote:
>
> > Ok - but it's a bit misleading having both values in /etc/services..
> >
> > Shouldn't be:
> > http 80/tcpwww www-http #World Wide Web HTTP
> > http 80/udpwww ww
On Fri, 30 Jul 1999, Doug wrote:
> The -n option to trafshow disables number->name translation for
> both addresses and ports, although that might be more than what is wanted.
> I do know what you mean though. On some of the machines I administer I
> have some custom entries for /etc/service
On Fri, Jul 30, 1999 at 10:56:55PM +0900, Daniel C. Sobral wrote:
>
> I said that I did not care whether the thing is inside or outside
> the regexp library.
Yes, although I think at this point it's obvious we're coming at this
discussion from fairly different perspectives. By the time you
broug
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote:
>
> > it was VERY simple to do... and attached is the patch... this uses the
> > option REG_STARTEND to do what the copy was trying to do... all of the
> > code to use REG_STARTEND was already there, it just needed to be enabled..
On Fri, 30 Jul 1999, Guy Helmer wrote:
# Have you tried booting with the "-v" flag to see the driver's probe
# messages? Did you configure the card using the configuration "pnp"
# commands before the kernel starts booting? For example,
I did the former but not the latter. I'll stick it in a
ma
In message <8605.933365...@zippy.cdrom.com> "Jordan K. Hubbard" writes:
: It already is. That's not the question under discussion here - we're
: talking about how to make things work in the post-installation boot
: scenario.
I'm in favor of having it in the kernel by default. With one
proviso.
In message "Brian
F. Feldman" writes:
: And how about having
: if (securelevel > 3)
: return (EPERM);
: in bpf_open()?
There are no security levels > 3. I'd be happy with > 0. This is
consistant with the meaning of "raw devices".
Warner
To Unsubscribe: send mail to ma
On Fri, 30 Jul 1999, Warner Losh wrote:
> In message
> "Brian F. Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of "raw
In message
Alfred Perlstein writes:
: What about the one-way sysctls that have been suggested?
They need to be implemente dfirst. A quick securelevel > 0 in bpf_open
would allow many people's objections to bpf in the kernel by default.
Warner
To Unsubscribe: send mail to majord...@freebsd.o
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of "raw devices".
Would you be willing to make this change?
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
In message <9518.933378...@zippy.cdrom.com> "Jordan K. Hubbard" writes:
: > There are no security levels > 3. I'd be happy with > 0. This is
: > consistant with the meaning of "raw devices".
:
: Would you be willing to make this change?
Yes. I will make this change tomorrow unless there is sig
Spent quite a bit of time today playing around with the newly
repaired readdirplus option for nfs clients in -current. My thanks to Matt
Dillon and Bill Paul. For those that don't remember, I'm trying to use
amd/nfs client stuff on some freebsd web servers that read their data from
our sun
On Fri, 30 Jul 1999, Doug wrote:
> Spent quite a bit of time today playing around with the newly
> repaired readdirplus option for nfs clients in -current. My thanks to Matt
> Dillon and Bill Paul. For those that don't remember, I'm trying to use
> amd/nfs client stuff on some freebsd web se
:In message <9518.933378...@zippy.cdrom.com> "Jordan K. Hubbard" writes:
:: > There are no security levels > 3. I'd be happy with > 0. This is
:: > consistant with the meaning of "raw devices".
::
:: Would you be willing to make this change?
:
:Yes. I will make this change tomorrow unless there
: Spent quite a bit of time today playing around with the newly
:repaired readdirplus option for nfs clients in -current. My thanks to Matt
:Dillon and Bill Paul. For those that don't remember, I'm trying to use
:amd/nfs client stuff on some freebsd web servers that read their data from
:our
:
:> amd.Interfaces:
:>
:> /defaults type:=nfs;opts:=rw,vers=3,readdirplus,intr,proto=udp
:>
:> * rhost:=IP${key};rfs:=/Space/${key}
:
:Not to rain on your parade, but Dag-Erling informed me that there
:was problems using NFSv3 over the loopback interface that can cause
:locku
:Anyway, Mr. Dillon, once I have a development box to smack around, I
:intend to start with your suggestion of implementing a filesystem
:of my own concoction by returning an error for all VOP calls and
:issuing a kernel printf. How visible will the new VOP code be to
:me at this level? The Peng
Warner Losh wrote:
>
> In message
> "Brian F. Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of "raw devices".
Dis
:> consistant with the meaning of "raw devices".
:
:Disabling bpf it will break rarpd (and also rbootd but it is less
:important). I think such a thing should be mentioned in documentation.
:
:-SB
Not if rarpd is started via the rc files... it would hook up to bpf
prior to the secureleve
On Fri, 30 Jul 1999, Matthew Dillon wrote:
> The only other major feature is the nq leasing stuff for cache coherency,
> but it is highly experimental and you probably shouldn't use it. Plus
> very few other OS's support it.
heh... I'm just happy when the stuff works that's s
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote:
>
> Funnily, I experience a near-doubling of running time with similar
> patches.
Incidentally, it seems that it's not possible to assume that our
regex library is even anywhere in the same league as the GNU regex
library.
b$ t
In message <37a25361.34799...@bellatlantic.net> Sergey Babkin writes:
: Disabling bpf it will break rarpd (and also rbootd but it is less
: important). I think such a thing should be mentioned in documentation.
Not if they are started before the secure level is raised.
Warner
To Unsubscribe: s
Unsubscribe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Unsubscribe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Unsubscribe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
http://features.linuxtoday.com/stories/8191.html
A story on upcoming plans for the Linux 2.4 kernel. Since they're
going after a lot of the same performance goals we are, it's worth a
read.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the bo
On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
> http://features.linuxtoday.com/stories/8191.html
>
> A story on upcoming plans for the Linux 2.4 kernel. Since they're
> going after a lot of the same performance goals we are, it's worth a
> read.
It seems to me that a lot of the features mention
On Sat, 31 Jul 1999, kylee wrote:
> Unsubscribe
No.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
If memory serves, didn't John Reynolds~ say:
>
> 1) The sound card make and model/chipset. Please be as specific as you
> can with board rev numbers if possible. Please include wether the card is
> ISA or PCI.
Crystal Tidalwave32 -- plug-n-play ISA card
CSN 1 Vendor ID: XTL0005 [0x05008c62]
> 2)
On Fri, 30 Jul 1999, Alex Zepeda wrote:
> On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
>
> > http://features.linuxtoday.com/stories/8191.html
> >
> > A story on upcoming plans for the Linux 2.4 kernel. Since they're
> > going after a lot of the same performance goals we are, it's worth a
> > r
- jir ji jimaria j...@logx.com irc#tokyo15 icq jir 3941247-
http://www.enjoynight.com/cgi-bin/friends/ji/familychat.cgi
VAIO PCG-C1 FreeBSD
be late sorry
Thunks kindness to Mr Dirk GOUDERS
From: Dirk GOUDERS
Subject: Re: [FreeBSD-net-jp 1746] [FYI] Adaptec AIC-6915 "Starfire"
ethernet controll
> I would like to change the IP address (netmask, gateway etc.) of an Interface
> (eg. fxp0) from within my C source code.
>
> 1. Is this possible to do without the SIOC ioctl call? (i am already in the
> kernel).
Make the call from within the kernel.
> 2. Which structure and which member shoul
>
> I've come up empty-handed hunting for a constant that defines the
> maximum UID supported by the system. I'm working on our passwd and
> pwd_mkdb stuff and want to get rid of the artificial limitation of 65535
> (USHRT_MAX) imposed in (at least) pwd_mkdb.
>
> Have I missed a useful define, o
> I'l looking at defining about a dozen ioctl calls for a local device driver.
> When looking at the _IO, _IO, _IOW, _IOR, and _IOWR macros, I'm interested if
> there are any "reserved" or "local" values for the first parameter?
Not really, as such.
> In short, I'd hate to use a seemly unused
On Thu, 29 Jul 1999, Martin Cracauer wrote:
> In
><[EMAIL PROTECTED]>,
> Rayson Ho wrote:
> > Hi,
> >
> > I am not sure whether this is known to this list or
> > not, but here is the URL for ordering:
> >
> > http://www.bsdi.com/products/evalcd/
>
> The thing that gets my attention is the g
Mike Smith wrote:
> > I would like to change the IP address (netmask, gateway etc.) of an Interface
> > (eg. fxp0) from within my C source code.
> >
> > 1. Is this possible to do without the SIOC ioctl call? (i am already in the
> > kernel).
>
> Make the call from within the kernel.
But I was un
> Mike Smith wrote:
>
> > > I would like to change the IP address (netmask, gateway etc.) of an Interface
> > > (eg. fxp0) from within my C source code.
> > >
> > > 1. Is this possible to do without the SIOC ioctl call? (i am already in the
> > > kernel).
> >
> > Make the call from within the ker
hi, there!
On Mon, 26 Jul 1999, Steven Fletcher wrote:
> I've seen the PAM modules/libraries/etc for MySQL and noticed that the
> FTPD Makefile has a Kerberos PAM option, and was wondering if anyone
> knows of a way to get FTPd talking to MySQL... or if it would work at
> all?
ftpd PAM patches
Sorry I know i should not mail to the mailinglist. But I can not unsubscribe
Please help me
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
[EMAIL PROTECTED] (Wes Peters) writes:
> [ENOBUFS] Insufficient system buffer space exists to complete the op-
>eration.
Do you know what kind of circumstances that error *really* occurs
under?
If it happened with files, that would be a bug and should be fixed.
The
On Fri, 30 Jul 1999 00:53:56 MST, Mike Smith wrote:
> It probably belongs in param.h, and you can probably safely calculate it
> as (uid_t)0 - 1;
Excellent.
Another question I should have asked in my original mail is this: are
there magical reasons why we should want pwd_mkdb to bleat for eve
Hi!
As I promised earlier, here is some information how to
integrate KAME and PAO into the FreeBSD 3.2-RELEASE
source tree.
The current status is:
- FreeBSD+KAME
- no conflicts during merge
- "make world" is working
- systems are up and running without any problems :-)
- FreeBSD+PA
1 - 100 of 178 matches
Mail list logo
