From owner-freebsd-hackers Wed Apr 18 7: 6:33 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id BA4F237B422 for ; Wed, 18 Apr 2001 07:06:30 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3IE55f02718; Wed, 18 Apr 2001 10:05:05 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 18 Apr 2001 10:05:05 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp Cc: Kirk McKusick , Julian Elischer , Rik van Riel , freebsd-hackers@FreeBSD.ORG, Matt Dillon , David Xu Subject: Re: vm balance In-Reply-To: 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 Wed, 18 Apr 2001, Robert Watson wrote: > On Wed, 18 Apr 2001, Poul-Henning Kamp wrote: > address spaces, can be opened/closed and retain a seeking position, can be This is what I get for sending messages in the morning after staying up late -- needless to say, you can ignore the "retain a seeking position" statement: vnodes generally don't operate with a notion of "position", that occurs at the struct file level. It's arguable, if you had stateful vnodes, that you might want to push the seek operation down from the open file layer, as devices might want to implement the seeking service themselves. In any case, this is not a problem that moving the device operations into the struct file array will fix--in fact, it's arguable for devices wanting to offer services to different consumers on the same instance (such as /dev/vmmon), you want the vnode reference counting notion of open/close + the sprinkled state vnode design we've discussed before, which would allow VFS and the struct file layer to do the state management binding state to consumers, rather than teaching the device layer how to do that. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message