From owner-freebsd-hackers Tue May 18 9:59:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nomad.dataplex.net (nomad.nobell.com [216.140.184.67]) by hub.freebsd.org (Postfix) with ESMTP id CC40414F60 for ; Tue, 18 May 1999 09:59:41 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from localhost (rkw@localhost) by nomad.dataplex.net (8.9.2/8.9.3) with ESMTP id LAA02045; Tue, 18 May 1999 11:59:26 -0500 (CDT) (envelope-from rkw@dataplex.net) X-Authentication-Warning: nomad.dataplex.net: rkw owned process doing -bs Date: Tue, 18 May 1999 11:59:26 -0500 (CDT) From: Richard Wackerbarth Reply-To: rkw@dataplex.net To: Mike Smith Cc: Marc Slemko , hackers@FreeBSD.ORG Subject: Re: libkvm sucks In-Reply-To: <199905181613.JAA03949@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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