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
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
