On Wed, 18 Apr 2001, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Kirk McKusick writes:
>
> >Every vnode in the system has an associated object.
>
> No: device vnodes dont...
>
> I think the correct solution to that is to move devices away from vnodes
> and into the fdesc layer, just like fifo's and sockets.
I dislike that idea for a number of reasons, not least of which is that
introducing more and more file-descriptor level objects increases the
complexity of the system call service implementation, and duplicates code.
If we're going to pretend that everything in the system is a file, and
most people seem willing to accept that, acting on devices through vnodes
seems like a reasonable choice. The vnode provides us with a notion of
open/close, reference counting, access to a generic vnode pager for memory
mapping of objects without specific memory mapping characteristics, and so
on. Right now, the mapping from vnodes into devices is a bit poor due to
some odd reference / open / close behavior, and due to a lack of a notion
of stateful access to vnodes (there have been a number of proposals to
remedy this, however). 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. It may not be a perfect
representation of a device, but it does a reasonable job. 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 :-).
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
