Subject: Re: Playing Audio CDs under NetBSD/sparc!
To: Pete Delaney <pete@RockyMountain.Rahul.Net>
From: Ask Dr. Stupid <greywolf@defender.VAS.viewlogic.com>
List: current-users
Date: 11/02/1995 09:36:21
Do you mean that Sun now does locking in the kernel under Slowlaris as
opposed to SunOS, or do you mean that Sun has always done it in kernel
space instead of user space?

If the former, then why does Solaris still need /usr/lib/nfs/lockd?

If the latter, then why do either of them need a lockd?  Should not locking
be automagically received, or does the daemon need to sit in user space
to field the requests?

And if the lockd is just sitting there fielding requests, why should there
be more than one instantiation of lockd?  I have yet to see an implementation
which does this.

#define AUTHOR "pete@RockyMountain.Rahul.Net (Pete Delaney)"

/*
 * 
 *    > 
 *    > > It makes me very very happy to be able to announce that myself and 
 *    > > Matthew Green, yesterday got audio cds to play from NetBSD/sparc. xmcd 
 *    > > version-2 has NetBSD support and after creating the new cd devices
 *    > > from MAKEDEV and selecting /dev/rcd0c I could play audio cds through my 
 *    > > cd player! This was the last reason to use SunOS on a sparc in my opinion :-)
 *    > > 
 *    > 	In a commercial environment there is one more reason to use SunOS:
 *    > 
 *    > 	Network lock management (or lack thereof)...
 *    > 
 *    > 	I've been whining for well over a year on this point and noone thinks
 *    > 	it important enough to work on in ANY of the free OS's... B^(.
 *    > 
 *    > 	Many commercial apps, right or wrong, REQUIRE lockd and statd
 *    > 	functions in order to fire up; they insist on kernel locking the file(s)
 *    > 	they are working on. Without lockd/statd NetBSD and the other
 *    > 	Free OS's can't be used as commercial servers which is one
 *    > 	area they would REALLY shine.
 *    > 
 *    > 	Has anybody looked in to getting kernel lock management over straight
 *    > 	NFS going on any of the Free OS's? Even something that would fake
 *    > 	out the lock services at the risk of trashing files?
 * 
 * I'd recomend that lock management, if done, be done just like nfs, IN THE KERNEL.
 * Sun had addopted this approach and has given up on the stupid approach of doing
 * it in a User Sparce daemon. It's actually much simplier than NFS.  Also, I'd
 * recomend implementing the SYNCHRONOUS version, at least in addition to the
 * STUPID ASYNC version. You can get around the problem to the lockd server
 * sending RPC's by have the number of lockd`s running in kernel space dynamicly
 * adjust to the needs, always leaving a lockd or two to handle incoming RPC's.
 * 
 * -pete    
 * 
 */

#undef AUTHOR	/* "pete@RockyMountain.Rahul.Net (Pete Delaney)" */




				--*greywolf;
--
Are you being infected by a UNIX virus?  If you're receiving OS shipments
from your vendor, you may be subjecting your computer to the worst virus
in history: SVR4.  There is a cure for this virus:  upgrade to NetBSD
(now running on a platform near you).