Date: Wed, 18 Apr 2001 10:05:05 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Kirk McKusick <mckusick@mckusick.com>, Julian Elischer <julian@elischer.org>, Rik van Riel <riel@conectiva.com.br>, freebsd-hackers@FreeBSD.ORG, Matt Dillon <dillon@earth.backplane.com>, David Xu <bsddiy@21cn.com> Subject: Re: vm balance Message-ID: <Pine.NEB.3.96L.1010418100011.2462C-100000@fledge.watson.org> In-Reply-To: <Pine.NEB.3.96L.1010418094428.2462A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010418100011.2462C-100000>