Date: Wed, 18 Apr 2001 11:28:11 -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.1010418111539.2462G-100000@fledge.watson.org> In-Reply-To: <38778.987605692@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Apr 2001, Poul-Henning Kamp wrote: > >The vnode is our abstraction for objects that have > >address spaces, can be opened/closed and retain a seeking position, can be > >mapped, have protections, etc, etc. > > This is simply not correct Robert, UNIX::sockets also have many of those > properties, but they're not vnodes... As I indicated in my follow-up mail, the statement about seeking was incorrect, that is a property of the open file structure; I believe the remainder still holds true. When was the last time you tried mmap'ing or seeking on the socket? A socket represents a buffered data stream which does not allow arbitrary read/write operations at arbitrary offsets. I guess what I'd really like to see is this: for devices that provide an address space service (such as disks), vnodes would be used. For devices that represent streams (such as many pseudo-devices and ttys), they would be represented by a slightly improved socket abstraction. The socket is a somewhat poor abstraction for this right now, perhaps a vstream would be a better concept. > >Besides which, > >the kernel knows how to act on vnodes, and there is plenty of precedent > >for the kernel opening vnodes and keeping around references for its own > >ends, but there isn't all that much precedent for the kernel doing this > >using file descriptors :-). > > Have you actually examined how FIFO and Sockets work Robert ? :-) What I'm refering to is the fact that the kernel frequently keeps open vnodes for use internally in various sorts of operations, such as quotas, accounting, core dumps, etc. BTW, part of the problem here may be a terminology problem: for me, a file descriptor refers to the per-process reference in the file descriptor table. What you appear to refer to here is the open file entry, struct file, which stores the operation array, seeking location, cached credential, etc. 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.1010418111539.2462G-100000>