SCHED_RR(root only!?) vs SCHED_FIFO(any user!?)
Hi all!
Can anyone please explain why I have to be root (or make the executable
run as root) to be able to use SCHED_RR in my LinuxThreads (btw, same
thing happens in pthreads) application?
pthread_create() returns an "Operation not permitted" error if not run
as root.
My application *must not* run as root (there is no need for it to) but I
also *must have* Round-Robin scheduling for overall system (application)
stability and availability.
Please help! (And, [EMAIL PROTECTED] doesn't respond to my subscribe
requests so please reply in private)
//Bjorn
pthread_attr_t attr;
/* Set scheduling policy to Round-Robin so that all threads will have a
chance to
run. In extreme environments, the default first-in first-out
scheduler is used,
and some threads might never get a chance to run. */
if ((status = pthread_attr_setschedpolicy(&attr, SCHED_RR)) != 0)
{
cerr << "WARNING: Thread scheduling policy defaults to FIFO!!! Some
threads "
"might never run!" << endl;
cerr << " Reason given: " << strerror(status) << endl;
}
if ((status = pthread_create(&myThreadID, &attr, &thread_func, this)) !=
0)
{
cout << strerror(status)<< endl;
throw "Thread could not be created";
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Multiple ro mounts of vinum volume
Does anybody with a knowledge of the vinum code have an opinion on the amount of work involved in getting vinum to the point that several JBODs in a FC switched fabric could be managed, as a vinum volume, by one machine, and mounted ro by that machine and several others on the switch fabric. (writing to that volume is obviously a fs issue) -- GeoffB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple ro mounts of vinum volume
On Thursday, 20 July 2000 at 9:55:13 +0100, Geoff Buckingham wrote: > > Does anybody with a knowledge of the vinum code have an opinion on > the amount of work involved in getting vinum to the point that > several JBODs in a FC switched fabric could be managed, as a vinum > volume, by one machine, and mounted ro by that machine and several > others on the switch fabric. I'd say "no work at all" as far as Vinum is concerned. The real issue is getting the drivers to present the individual drives to the system. That's a device driver issue, and I don't know enough about the current state of FC drivers to make a sensible comment. But I'd certainly be interested to hear more. > (writing to that volume is obviously a fs issue) That depends if you want to put a file system on it. A thing that might bite you here is that ufs is currently limited to 1 TB per volume. Vinum doesn't have that restriction: if you want to create a 20 TB volume, and you know how to use the space, Vinum should work. The problem with ufs is that the block numbers in the inodes are 32 bit signed values. With 512 byte sectors, the only we can do it, that means a total address space of 2**9 * 2*31, or 1 TB. At some time I suspect we're going to need to fix that. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple ro mounts of vinum volume
On Thursday, 20 July 2000 at 18:33:42 +0930, Greg Lehey wrote: > On Thursday, 20 July 2000 at 9:55:13 +0100, Geoff Buckingham wrote: >> >> Does anybody with a knowledge of the vinum code have an opinion on >> the amount of work involved in getting vinum to the point that >> several JBODs in a FC switched fabric could be managed, as a vinum >> volume, by one machine, and mounted ro by that machine and several >> others on the switch fabric. > > I'd say "no work at all" as far as Vinum is concerned. The real issue > is getting the drivers to present the individual drives to the > system. That's a device driver issue, and I don't know enough about > the current state of FC drivers to make a sensible comment. But I'd > certainly be interested to hear more. > >> (writing to that volume is obviously a fs issue) Oops, I missed the point here. Yes, the multiple R/O issue would make it very difficult to write to it. I suspect that it would be almost impossible to write while other systems had the volume open R/O. I'll think about how that could be done, but it's not simple, if it's at all possible. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple ro mounts of vinum volume
On Thu, Jul 20, 2000 at 06:38:13PM +0930, Greg Lehey wrote: > On Thursday, 20 July 2000 at 18:33:42 +0930, Greg Lehey wrote: > > On Thursday, 20 July 2000 at 9:55:13 +0100, Geoff Buckingham wrote: > >> > >> Does anybody with a knowledge of the vinum code have an opinion on > >> the amount of work involved in getting vinum to the point that > >> several JBODs in a FC switched fabric could be managed, as a vinum > >> volume, by one machine, and mounted ro by that machine and several > >> others on the switch fabric. > > > > I'd say "no work at all" as far as Vinum is concerned. The real issue > > is getting the drivers to present the individual drives to the > > system. That's a device driver issue, and I don't know enough about > > the current state of FC drivers to make a sensible comment. But I'd > > certainly be interested to hear more. > > I believe all the disks should be visable to all the hosts, unless some aspect of your switch fabric has been configured to hide disks from NT4 boxes. > >> (writing to that volume is obviously a fs issue) > > Oops, I missed the point here. Yes, the multiple R/O issue would make > it very difficult to write to it. I suspect that it would be almost > impossible to write while other systems had the volume open R/O. I'll > think about how that could be done, but it's not simple, if it's at > all possible. > I would be happy with unmounting the FS everywhere mounting it rw on the 'management' machine , writing, then reversing back to having it mounted ro everywhere. I may have a play with this in a few months when I have a bit more kit, as I had imagined there would be more issues with multiple machines, each with an instance of vinum trying to manage the same single volume (particulary in degraded or repair situations) On the Fs front I must confess to having lost track of the XFS situation/ devate after the intial storm of interest when SGI first announced their interest. What happened? -- GeoffB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SCHED_RR(root only!?) vs SCHED_FIFO(any user!?)
On Thu, Jul 20, 2000 at 10:15:53AM +0200, Bjorn Tornqvist wrote: > > Hi all! > > Can anyone please explain why I have to be root (or make the executable > run as root) to be able to use SCHED_RR in my LinuxThreads (btw, same > thing happens in pthreads) application? 1) Note that the default scheduling policy in linuxthreads is SCHED_OTHER not SCHED_FIFO. SCHED_OTHER is a form of round robin scheduling. 2) SCHED_RR and SCHE_FIFO are "real time" policies in linuxthreads. FreeBSD (and Linux too, AFAIK) limit root to setting real time policies because setting such a policy can potentially monopolize a machine, effectively resulting in a local DoS. There may also be potential priority inversion problems that need to be dealt with when using real time policies. 3) I would have thought that FreeBSD user threads would let you manipulate policies as an ordinary user, but in any case, AFAIK the default policy in user threads is SCHED_RR. AFAIK, SCHED_RR and SCHED_FIFO are not "real time" policies in FreeBSD user threads (when applied to thread scheduling -- they are still real time policies when applied to the scheduling of the process). > My application *must not* run as root (there is no need for it to) but I > also *must have* Round-Robin scheduling for overall system (application) > stability and availability. Why is the default SCHED_OTHER not acceptable for your app? I would think stability and availability would be improved with SCHED_OTHER, except in very restricted situations? -- Richard Seaman, Jr.email:[EMAIL PROTECTED] 5182 N. Maple Lane phone:262-367-5450 Nashotah WI 53058fax:262-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
memory type and its size
Does kernel memory of the same type (e.g., M_TEMP) must be allocated (using malloc()) with the same (range of) size? BTW, how to display mbuf cluster usages info. Thanks. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
T-Beach Multisound Monterey device driver upgraded to FBSD-4.0
I have upgraded my device driver for the subject soundcard. For features, capabilities, limitations and downloading see: http://www.treefort.org/~bobkat/msm20/9main.shtml This version has many bug fixes since the FBSD-3.x version. It is still dual mode. KLD module can be kldload/kldunload'd and is the preferred mode of use, but it can be compiled statically into a kernel. The KLD module mode of installation has been facilitated via a sh script. Are there any device driver authors out there who are implementing their driver as a KLD module and delivering/installing it as a port? This version is being released under the less restrictive FreeBSD free-software license. Fiji and Pinnacle models will not work with this driver. They are similar to the Monterey but the Turtle Beach interface to the hardware changed in later models. Push that mixer slider up and enjoy some tunes!! 1 3 0 1 3 13013 BOB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problem on 4.1-RC (4.0-stable)
On Wed, Jul 19, 2000 at 01:02:59PM -0700, Kent Stewart wrote: > > > Ulf Zimmermann wrote: > > > > On Tue, Jul 18, 2000 at 09:09:47PM -0700, Kent Stewart wrote: > > > > > > > > > Ulf Zimmermann wrote: > > > > > > > > Hello, > > > > > > > > I updated via cvsup (cvsup from tuesday afternoon PDT), I went into > > > > single user mode, did make world, make buildkernel KERNEL=FOURTYTWO > > > > and make installkernel KERNEL=FOURTYTWO. Everything but one thing > > > > I can find seems to work fine, but ps doesn't. > > > > > > Did you boot /FOURTYTWO or do the rename sequence to make it kernel? > > > It sounds like your kernel and world might be a little out of > > > sequence. > > > > I did the move. I rebuild the kernel again, same file size got created. > > Yes, I agree it sounds like stuff is out of sync, but I did the complete > > world after I cvsup and made the kernel. > > I thought it was something simple. I'm running 4.1-RC on 3 computers > and ps works on all of them. Having something out of sequence could > produce symptoms like that. > > FWIW, 4.1-RC is broken right now when you try to build the netinet > section. So you can't cvsup to make sure didn't grab files in the > middle of an upgrade. Sigh, so I did another cvsup around 9am PDT today and did: make buildworld make buildkernel KERNEL=FOURTYTWO make installkernel KERNEL=FOURTYTWO make installworld then did the chflags, mv etc of the kernel, rebooted and still: fourtytwo ulf home/ulf > ps ps: bad namelist fourtytwo ulf home/ulf > which ps /bin/ps fourtytwo ulf home/ulf > ll /bin/ps 216 -r-xr-xr-x 1 root wheel 207748 Jul 20 15:30 /bin/ps fourtytwo ulf home/ulf > ll /kernel 2560 -r-xr-xr-x 1 root wheel 2605561 Jul 20 15:29 /kernel Anyone got any idea why ? > > Kent > > > > > > > > > Kent > > > > > > > > > > > Trying to use ps: > > > > > > > > fourtytwo ulf home/ulf > ps > > > > ps: bad namelist > > > > > > > > Rebuilding kerbel, libkvm or ps produce the same bins. "bad namelist" > > > > is in error inside of libkvm (kvm_i386.c) after using kvm_nlist. > > > > > > > > Anyone got an suggestion what to check or what maybe broken ? > > > > > > > > -- > > > > Regards, Ulf. > > > > > > > > - > > > > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > > > > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > -- > > > Kent Stewart > > > Richland, WA > > > > > > mailto:[EMAIL PROTECTED] > > > http://kstewart.urx.com/kstewart/index.html > > > FreeBSD News http://daily.daemonnews.org/ > > > > > > Bomber dropping fire retardant in front of Hanford Wild fire. > > > http://kstewart.urx.com/kstewart/bomber.jpg > > > > -- > > Regards, Ulf. > > > > - > > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > Kent Stewart > Richland, WA > > mailto:[EMAIL PROTECTED] > http://kstewart.urx.com/kstewart/index.html > FreeBSD News http://daily.daemonnews.org/ > > Bomber dropping fire retardant in front of Hanford Wild fire. > http://kstewart.urx.com/kstewart/bomber.jpg -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problem on 4.1-RC (4.0-stable)
On Thu, 20 Jul 2000, Ulf Zimmermann wrote: > and still: > > fourtytwo ulf home/ulf > ps > ps: bad namelist You're not bypassing the loader when you boot are you? Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problem on 4.1-RC (4.0-stable)
On Thu, Jul 20, 2000 at 03:48:23PM -0700, Kris Kennaway wrote: > On Thu, 20 Jul 2000, Ulf Zimmermann wrote: > > > and still: > > > > fourtytwo ulf home/ulf > ps > > ps: bad namelist > > You're not bypassing the loader when you boot are you? No, the machine is a pure FreeBSD machine, but uses the 3 stage boot loader. > > Kris > > -- > In God we Trust -- all others must submit an X.509 certificate. > -- Charles Forsythe <[EMAIL PROTECTED]> > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problem on 4.1-RC (4.0-stable)
hey ulf, i bet your /dev/null is no longer nulling: # cd /dev # rm null # echo "fuck" > null # ps ax ps: bad namelist -- yan On Thu, Jul 20, 2000 at 03:39:53PM -0700, Ulf Zimmermann <[EMAIL PROTECTED]> wrote: > On Wed, Jul 19, 2000 at 01:02:59PM -0700, Kent Stewart wrote: > > > > > > Ulf Zimmermann wrote: > > > > > > On Tue, Jul 18, 2000 at 09:09:47PM -0700, Kent Stewart wrote: > > > > > > > > > > > > Ulf Zimmermann wrote: > > > > > > > > > > Hello, > > > > > > > > > > I updated via cvsup (cvsup from tuesday afternoon PDT), I went into > > > > > single user mode, did make world, make buildkernel KERNEL=FOURTYTWO > > > > > and make installkernel KERNEL=FOURTYTWO. Everything but one thing > > > > > I can find seems to work fine, but ps doesn't. > > > > > > > > Did you boot /FOURTYTWO or do the rename sequence to make it kernel? > > > > It sounds like your kernel and world might be a little out of > > > > sequence. > > > > > > I did the move. I rebuild the kernel again, same file size got created. > > > Yes, I agree it sounds like stuff is out of sync, but I did the complete > > > world after I cvsup and made the kernel. > > > > I thought it was something simple. I'm running 4.1-RC on 3 computers > > and ps works on all of them. Having something out of sequence could > > produce symptoms like that. > > > > FWIW, 4.1-RC is broken right now when you try to build the netinet > > section. So you can't cvsup to make sure didn't grab files in the > > middle of an upgrade. > > Sigh, so I did another cvsup around 9am PDT today and did: > > make buildworld > make buildkernel KERNEL=FOURTYTWO > make installkernel KERNEL=FOURTYTWO > make installworld > > then did the chflags, mv etc of the kernel, rebooted > > and still: > > fourtytwo ulf home/ulf > ps > ps: bad namelist > fourtytwo ulf home/ulf > which ps > /bin/ps > fourtytwo ulf home/ulf > ll /bin/ps > 216 -r-xr-xr-x 1 root wheel 207748 Jul 20 15:30 /bin/ps > fourtytwo ulf home/ulf > ll /kernel > 2560 -r-xr-xr-x 1 root wheel 2605561 Jul 20 15:29 /kernel > > > Anyone got any idea why ? > > > > > Kent > > > > > > > > > > > > > Kent > > > > > > > > > > > > > > Trying to use ps: > > > > > > > > > > fourtytwo ulf home/ulf > ps > > > > > ps: bad namelist > > > > > > > > > > Rebuilding kerbel, libkvm or ps produce the same bins. "bad namelist" > > > > > is in error inside of libkvm (kvm_i386.c) after using kvm_nlist. > > > > > > > > > > Anyone got an suggestion what to check or what maybe broken ? > > > > > > > > > > -- > > > > > Regards, Ulf. > > > > > > > > > > - > > > > > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > > > > > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > > > -- > > > > Kent Stewart > > > > Richland, WA > > > > > > > > mailto:[EMAIL PROTECTED] > > > > http://kstewart.urx.com/kstewart/index.html > > > > FreeBSD News http://daily.daemonnews.org/ > > > > > > > > Bomber dropping fire retardant in front of Hanford Wild fire. > > > > http://kstewart.urx.com/kstewart/bomber.jpg > > > > > > -- > > > Regards, Ulf. > > > > > > - > > > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > > > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > -- > > Kent Stewart > > Richland, WA > > > > mailto:[EMAIL PROTECTED] > > http://kstewart.urx.com/kstewart/index.html > > FreeBSD News http://daily.daemonnews.org/ > > > > Bomber dropping fire retardant in front of Hanford Wild fire. > > http://kstewart.urx.com/kstewart/bomber.jpg > > -- > Regards, Ulf. > > - > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problem on 4.1-RC (4.0-stable)
On Thu, Jul 20, 2000 at 04:51:46PM -0700, Jan Koum wrote: > hey ulf, i bet your /dev/null is no longer nulling: > > # cd /dev > # rm null > # echo "fuck" > null > # ps ax > ps: bad namelist Yep, you were right. /dev/null was a plain file. Strange > > > -- yan > > On Thu, Jul 20, 2000 at 03:39:53PM -0700, Ulf Zimmermann <[EMAIL PROTECTED]> wrote: > > On Wed, Jul 19, 2000 at 01:02:59PM -0700, Kent Stewart wrote: > > > > > > > > > Ulf Zimmermann wrote: > > > > > > > > On Tue, Jul 18, 2000 at 09:09:47PM -0700, Kent Stewart wrote: > > > > > > > > > > > > > > > Ulf Zimmermann wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > I updated via cvsup (cvsup from tuesday afternoon PDT), I went into > > > > > > single user mode, did make world, make buildkernel KERNEL=FOURTYTWO > > > > > > and make installkernel KERNEL=FOURTYTWO. Everything but one thing > > > > > > I can find seems to work fine, but ps doesn't. > > > > > > > > > > Did you boot /FOURTYTWO or do the rename sequence to make it kernel? > > > > > It sounds like your kernel and world might be a little out of > > > > > sequence. > > > > > > > > I did the move. I rebuild the kernel again, same file size got created. > > > > Yes, I agree it sounds like stuff is out of sync, but I did the complete > > > > world after I cvsup and made the kernel. > > > > > > I thought it was something simple. I'm running 4.1-RC on 3 computers > > > and ps works on all of them. Having something out of sequence could > > > produce symptoms like that. > > > > > > FWIW, 4.1-RC is broken right now when you try to build the netinet > > > section. So you can't cvsup to make sure didn't grab files in the > > > middle of an upgrade. > > > > Sigh, so I did another cvsup around 9am PDT today and did: > > > > make buildworld > > make buildkernel KERNEL=FOURTYTWO > > make installkernel KERNEL=FOURTYTWO > > make installworld > > > > then did the chflags, mv etc of the kernel, rebooted > > > > and still: > > > > fourtytwo ulf home/ulf > ps > > ps: bad namelist > > fourtytwo ulf home/ulf > which ps > > /bin/ps > > fourtytwo ulf home/ulf > ll /bin/ps > > 216 -r-xr-xr-x 1 root wheel 207748 Jul 20 15:30 /bin/ps > > fourtytwo ulf home/ulf > ll /kernel > > 2560 -r-xr-xr-x 1 root wheel 2605561 Jul 20 15:29 /kernel > > > > > > Anyone got any idea why ? > > > > > > > > Kent > > > > > > > > > > > > > > > > > Kent > > > > > > > > > > > > > > > > > Trying to use ps: > > > > > > > > > > > > fourtytwo ulf home/ulf > ps > > > > > > ps: bad namelist > > > > > > > > > > > > Rebuilding kerbel, libkvm or ps produce the same bins. "bad namelist" > > > > > > is in error inside of libkvm (kvm_i386.c) after using kvm_nlist. > > > > > > > > > > > > Anyone got an suggestion what to check or what maybe broken ? > > > > > > > > > > > > -- > > > > > > Regards, Ulf. > > > > > > > > > > > > - > > > > > > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > > > > > > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > > > > > -- > > > > > Kent Stewart > > > > > Richland, WA > > > > > > > > > > mailto:[EMAIL PROTECTED] > > > > > http://kstewart.urx.com/kstewart/index.html > > > > > FreeBSD News http://daily.daemonnews.org/ > > > > > > > > > > Bomber dropping fire retardant in front of Hanford Wild fire. > > > > > http://kstewart.urx.com/kstewart/bomber.jpg > > > > > > > > -- > > > > Regards, Ulf. > > > > > > > > - > > > > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > > > > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > -- > > > Kent Stewart > > > Richland, WA > > > > > > mailto:[EMAIL PROTECTED] > > > http://kstewart.urx.com/kstewart/index.html > > > FreeBSD News http://daily.daemonnews.org/ > > > > > > Bomber dropping fire retardant in front of Hanford Wild fire. > > > http://kstewart.urx.com/kstewart/bomber.jpg > > > > -- > > Regards, Ulf. > > > > - > > Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 > > Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to [EMAIL PROTECTE
Re: problem on 4.1-RC (4.0-stable)
On Thu, 20 Jul 2000, Jan Koum wrote: > hey ulf, i bet your /dev/null is no longer nulling: > > # cd /dev > # rm null > # echo "fuck" > null no... really. Tell us how you feel Jan. *chuckle* Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problem on 4.1-RC (4.0-stable)
On Thursday, July 20, 2000, Ulf Zimmermann wrote: > Yep, you were right. /dev/null was a plain file. Strange Just guessing here--ps probably uses /dev/null for all the files passed to kvm_open(3). I imagine it uses kvm_getprocs for its process listing, which is implemented using sysctl. -- |Chris Costello <[EMAIL PROTECTED]> |Programmer: One who is too lacking in people skills |to be a software engineer. `--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: T-Beach Multisound Monterey device driver upgraded to FBSD-4.0
In muc.lists.freebsd.hackers, you wrote: >Are there any device driver authors out there who are implementing >their driver as a KLD module and delivering/installing it as a port? You may look inside emulation/rtc or emulation/vmware port, it's not a drivers for hardware, but a KLD modules. -- Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
