Subject: Re: lockd issues
To: None <port-sparc@NetBSD.ORG>
From: Greg Earle <earle@isolar.Tujunga.CA.US>
List: port-sparc
Date: 11/03/1995 12:04:09
One last post on this subject, to answer Greywolf's questions ...

(Yes, Sun Engineering folks are spying on port-sparc  (-: )

	- Greg

------- Forwarded Message

To answer the specific question below, 99% of all the lock manager
work is done in the kernel.  The lockd exists primarily for
connection management.  It is a real pain to do all the endpoint
setup work, including name service lookups, from the kernel.

So the user level daemon creates the STREAM bound to a port and notfies
the portmapper.  It then makes a private system call to the kernel
to "register" the STREAM with the RPC kernel server.  Normal RPC traffic
stays inside the kernel, new connections bounce out to the daemon
which forks off another STREAM and registers it with the kernel.

It is the exact same mechanism that the NFS server uses.

>> 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.

------- End of Forwarded Message