Re: FreeBSD devfs support on NetBSD 5.0

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> (4) Structurally, permissions are (and should be) properties of the
>>> device driver, not of some intermediate devfs object.
>> I very strongly disagree with this.  For example, I see it as
>> totally reasonable to have different permissions on the very same
>> device in /dev and /ftp-chroot/dev and /ntp-chroot/dev
> That is entirely reasonable; the question is how best to accomplish
> it.

It can't be accomplished as long as the permissions are a property of
the device driver, is my point - indeed, it can't be done whenever
there *is* a "_the_ permissions" for a device driver.

Even your suggestion of using something nullfsish keeps the permissions
for all but one copy of the device in config files for the loopback
mounts - ie, somewhere other than the device driver you were saying
should be where they're kept.

>> I see devfs as a solution looking for a problem.
> There is a problem of sorts; there's a reason it's widely thought
> that some kind of devfs is a good idea, and and a reason why people
> try over and over to implement a useful one despite the repeated
> failures.

> However, the reason there are repeated failures is that the problem
> is deeper than generally realized and the solutions don't take this
> into account. :-/

Agreed on both counts.  There are a number of superficially attractive
things that lead in the direction of something devfsish, but when you
try to implement such a thing, you are brought up hard against some of
the more inevitable of the problems lurking....

> (I would characterize the underlying problem as "device special files
> are a hack.")

Possibly.  But what's the alternative?

You could move devices out of the filesystem entirely.  They could be
sockets, for example, or could be an entirely new kind of open file,
with new syscalls to create them.  (You could even make them accessed
other ways than with file descriptors, but that gets into even more
redesign weeds.)  I don't like this idea; there are already problems
enough laid at the door of the inability to do with sockets any analogs
to the things that chown, chmod, mv, ln, ln -s, etc, do with files.
Repeating the mistake for devices would be stupid and, I believe,
disastrous.

And if they're in the filesystem, you inherently have something very
much like today's device special files.  (The binding between a device
special file and the driver backing it is currently done with two
usually-small integers, but that's an implementation detail; the
essential part, for our purposes here, is that there is a filesystem
object that's somehow bound to the driver.)

Given these filesystem objects, I see no a priori reason to restrict
what you can do with them - that is, no reason why chown, chmod, mv,
etc, should not Just Work.  The only reason I can see is "it's too hard
to make that work", ie, implementation convenience.  While this is
certainly a valid reason in isolation, we already have an
implementation in which those do work.  Also relevant is that /dev
itself is just another directory, and the resulting flexibility is very
convenient at times.  (For example, the ability to have things other
than device special files in /dev, or to have multiple names which
connect to the same device but with different ownership, permissions,
or other attributes.)  Those who have used early Eunice, in which / and
/dev were not real directories but were faked up - actually, very much
like some of the devfs proposals - will understand how important this
flexibility can be.

I still hold that devfs is a solution looking for a problem.  The only
real benefit I've seen anyone cite to a devfs is the lack of need to
run MAKEDEV when hot-plugging something which wasn't anticipated when
/dev was built.  I would suggest that this can be provided for with a
userland daemon which listens for device attach/detach events (a new
kind of kevent, maybe?) and mutates /dev correspondingly.  It seems to
me this would get most of the benefit of the so-far-mostly-mythical
devfs while avoiding almost all of the prices that have kept it mostly
mythical so far.  Also, much of the necessary kernel infrastructure (a
generic framework to generate and handle device attach/detach events,
for example) is needed either way.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B