On Wed, 18 Apr 2001, Julian Elischer wrote:
> Poul-Henning Kamp wrote:
> >
> > In message <[EMAIL PROTECTED]>, Matt Dillon writes:
> > > If this will get rid of or clean up the specfs garbage, then I'm all
> > > for it. I would love to see a 'clean' fileops based device interface.
> >
> > specfs, aliased vnodes, you name it...
> >
> > I think the aliased vnodes is the single most strong argument of them
> > all for doing this...
>
> Great. Then we have aliased file pointers... that's not a great
> improvement..
>
> You'd still have to have 'per instance' storage somewhere, so that the
> openned devices could have different permissions, and still have them
> point to common data. so you still need aliases, except now it's not a
> vnode being aliased but some other structure.
As I justed stated in a private e-mail to Matt, I'm not opposed to the
idea of promoting devices to a first-class object (i.e., equivilent to
vnodes, rather than below vnodes) in FreeBSD, I just want to approach this
very cautiously, as there's a lot of obscure behavior in this area, and a
lot of portability concerns regarding the obscure behavior. In
particular, the "special case" of ttys is a very important special case --
operations such as revoke() must continue to work. With device operations
currently being pushed through VFS, VFS becomes a possible mediation point
for those operations, allowing "VFS magic" to be used on devices. If we
remove VFS from the call stack, we lose that capability. Poul-Henning has
successfully argued that this has a number of good implications, but we
need to make sure that the functionality lost there doesn't out-weight the
good bits.
One way to look at this disagreement might be the following: some people
feel that devices are simply evil, and not files, and shouldn't try to act
like them. Others feel that, modulo ioctl, we really can make devices
look like files, and should do that. The observation I tried to make in
an earlier e-mail was that it might be possible to accept the world-view
that "devices aren't files" by mapping some devices into a better
abstraction, such as the socket "data stream" concept, while still making
use of current abstractions. For example, using read() on /dev/audit
sucks, since what comes out of /dev/audit is a set of discrete records.
I'd rather use recv(), which has far superior semantics, since this is a
record-oriented data stream. The same goes for kernel log messages, which
on a discrete message-oriented stream could essentially become standard
syslog messages, rather than treating it as a text buffer with character
pointers. This would allow wrap-around to be handled much more cleanly,
by simply dropping records off one end of the record chain, rather than
severing lines and ending up with the current /dev/console abomination
(send too much to /dev/console -- i.e., single user mode, and dmesg
becomes useless).
I won't claim that moving to the slightly more abstracted viewpoint I
proposed earlier is the way to go, just that it's worth keeping in mind.
Maybe we should just throw up our hands and say "devices are devices,
screw files" -- this decision was made with NFS, and dramatically
simplifies the problem space.
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
