Date: Tue, 18 May 1999 11:59:26 -0500 (CDT) From: Richard Wackerbarth <rkw@dataplex.net> To: Mike Smith <mike@smith.net.au> Cc: Marc Slemko <marcs@znep.com>, hackers@FreeBSD.ORG Subject: Re: libkvm sucks Message-ID: <Pine.BSF.4.05.9905181151060.1961-100000@nomad.dataplex.net> In-Reply-To: <199905181613.JAA03949@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9905181151060.1961-100000>