On Tue, 18 May 1999, Mike Smith wrote: > > > > However, this applies to the functionality wherever it is implemented. > > Moving the formatting to the kernel does not change anything. > > It "changes" things in that it unnecessarily bloats the kernel. I agree. My reference was in relation to the the need for locks. Whether you are in the kernel or in userland, you need locks to get around race conditions.
> > If you are concerned about the time that it takes to do hostname lookups, > > that time is not any shorter in the kernel. > > You can't perform hostname lookups in the kernel. Today... (And I see no reason to add that functionality there) > > There are two fundamental approaches that work. > > > > 1) Lock the structure > > Make a snapshot copy > > Unlock the structure > > Generate the report from the copy > > Destroy the copy > > > > This technique can be used in either userland or kernel implementation. > > You can't lock kernel datastructures from userland (except for certain > very specific cases where the lock is a side-effect of another > operation). I again agree. The "lock, copy, unlock" sequence would probably be a single operation that userland requests the kernel to perform. > > 2) Use list traversal protocols that prevent the actual deletes from > > occurring while there is another list reader in that portion of the list. > > > > Again, the only requirement in the kernel is the ability set and clear the > > lock. The remainder of the formatting can occur outside the kernel > > because the structures being viewed and not destroyed during the > > traversal. > > This is where sysctl is preferable; the system call allows the kernel > to perform whatever locking protocol is required to complete the call > in a timely and efficient fashion, and all formatting can be performed > in userland while the kernel holds no locks. > > Consider the similarities to NFS directory traversals, and the cookie > approach used in NFSv3 to deal with server-side state changes during > traversal by the client. You're arguing about a problem that already > has several tried and tested solutions. I'm not arguing about anything. I'm stating that the technique is one possible solution to the "race" problem. To Unsubscribe: send mail to [email protected] with "unsubscribe freebsd-hackers" in the body of the message
