Subject: Re: Playing Audio CDs under NetBSD/sparc!
To: None <neil@domino.org, rhealey@kas.helios.mn.org>
From: Pete Delaney <pete@RockyMountain.Rahul.Net>
List: port-sparc
Date: 11/01/1995 14:28:08
   > 
   > > 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