Re: FreeBSD devfs support on NetBSD 5.0

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

>>> 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.
> True... but what do we do when the same issue arises for regular
> files?

"We"?  I usually make copies.  The issue rarely arises, though, because
for plain files, you _can_ make copies; with device special files,
there is only the one driver for a given device's functionality, so
there is no choice about what to use as the backing object.  This means
that moving permissions from the filesystem object to the backing
object loses flexibility.

> I guess the next question is this: why should a driver need to have
> multiple context-sensitive sets of permissions when no other system
> object does?

I don't think it should have _any_ sets of permissions; I think that's
the wrong place to keep permissions.

There is the filesystem object (the inode, traditionally) and something
backing it (data blocks, for plain files; a device driver, for device
special files).  Traditionally, permissions have been stored with the
filesystem object.  There is potential for an analogous problem, in
that it is impossible to have two plain-file filesystem objects sharing
the same data blocks (the only way to share data blocks is a hard link,
which is two directory entries pointing to the same filesystem object,
not two filesystem objects using the same data blocks).  This has
rarely-to-never been a problem in my experience; I speculate that it's
because there are comparatively few purposes for which a hardlink would
do but a copy wouldn't.  With device special files, the problem is
worse because, for given functionality, you have to use the same
backing object (there aren't multiple drivers for talking to the same
device); this means that there is no analog to making a copy of a plain
file - there is no way to create a different backing object to point
another filesystem object at; all the filesystem objects for a given
driver must use the same backing object.  This is why I think the
permissions belong on the filesystem objects rather than the backing
objects.  (I'd actually _like_ to see a way to have two plain-file
filesystem objects share the same backing object, the same data blocks,
but that may be more work than it's worth.)

> I don't have any good examples of chmod in /dev in mind, though.

I do.  For exmaple, on the machine to which I usually attach my
scanner, /dev/uk0 has been renamed to /dev/scanner and is either mode
666 or owned by mouse, I forget which.  The renaming could have been
handled (slightly wastefully) by a symlink, but I don't think allowing
mouse to access it could have.

>> Also, much of the necessary kernel infrastructure (a generic
>> framework to generate and handle device attach/detach events, for
>> example) is needed either way.
> It is much easier to build that framework (and make it reliable) if
> it doesn't have to pass to userlevel.  That's the catch.

I can't see why; it's just a question of having a (kernel) consumer of
the data that queues it for access from userland via whatever mechanism
is chosen.  What am I missing?

/~\ 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