On 2004-11-30 wrstuden@NetBSD.org wrote:
> On Tue, Nov 30, 2004 at 03:54:33AM -0500, Matthew Orgass wrote:
> > On 2004-11-29 wrstuden@NetBSD.org wrote:

> > > The biggest thing we gain with some sort of devfs vs new dev nodes is that
> > > we don't have to change any file systems; we aren't creating a new on-disk
> > > inode type.
> >
> >   Something else to consider might be how devfs would differ from an
> > improved mfs design containing these special nodes (plus some helper
> > tools).  I am fairly certain that everything a specialized devfs could do
> > could be arranged to work under a general mfs system with userland support
> > and a few minimally "special" additions, although some devfs possiblities
> > would work better than others this way.
>
> Well, mfs is ffs which is also ufs. So you're still talking about changing
> an on-disk file system. You're just suggesting limited changes to a
> probably-never-on-disk case.

  Unless a new mfs design is made.  However, modifying ufs would make it
possible for those who want to do so to have on disk nodes, but have this
disabled by default to retain compatability.

> >   A few other thoughts I don't remember reading yet (that may not be
> > entirely self consistant):
> >
> > * If there are separate per instance and default permissions on devices,
> > userland could do complex device recognition per instance without worrying
> > that the modified per instance permissions will accedently be applied to
> > the wrong device.  This could be implemented on a mfs or disk based system
> > by requiring that a device be "blessed" after it appears before named
> > device nodes successfully refer to the device (an option to autobless all
> > devices could also be available to allow fixed configuration similar to
> > current behavior).  A userland program would get an event notification
> > when devices are attached and removed and could remove the file at detach
> > (if desired) and add and set default permissions on all nodes that it
> > manages at attach time before blessing the device (of course, nodes that
> > it doesn't know about wouldn't be changed but use of nodev by default
> > except on those file systems intended to be used for mfs would avoid this
> > problem by default while allowing such nodes to be created if desired).
>
> Uhm, I don't think we need the "blessing" step as userland will be the
> agent creating the device node, in this scheme. Removing the node on
> deletion sounds good too.

  Something is needed to avoid a race condition with a new device taking
the name before the permissions are reverted, although the reference I
suggested for locators might be a better way to do this.  While any
references are held the device name will never be reused, so the userland
program holds a reference from attach until the node is deleted after
detach.

> > * I would like to see the permissions map separate from saved atimes, etc.
> > to reduce the chance of time update corrupting the map (which could be
> > more likely if everything lives in a single file) and so that it could
> > easily live on a read only file system.  This would make the most sense if
> > changing the permissions on a file in a mounted devfs did not change the
> > default but only the instance permissions.
>
> I think this idea would be a bad one. I much prefer keeping all of the
> information in one place. It strikes me as much simpler to audit if you
> only have to look in one file.
>
> As to issues involving errors on write, I think a rather simple solution
> is to have two copies of the file and ping-pong between them.

  If they are separate you can use a text file for the permissions map and
a binary file for the atime preservation.  IIRC you were advocating a
single permissions system with automatic tracking of the in use
permissions.  In that system, what you describe might make sense.  What I
was suggesting is that there is a file in /etc that contains the default
permissions based on cannonical device name (i.e.  device name + minor
number; major numbers would be directly replaced by symbolic names; I do
now see the problem with this, more below).  It also contains further
modifications to the permissions based on locator, but the altered
permissions will be applied to the cannonical device name.  Further
changes made to a running devfs by the admin would be applied only to that
instance and will go away forever when the device detaches.  This both
preserves cannonical reference and makes it possible to modify permissions
based on locator.  Use based on locator would need to be handled
separately.

  The main problem I see with automatic permission tracking is that with
permissions based on locators a simple chmod will not be an unambiguous
permissions change unless you also require the admin to know all possible
locators in order to difinitively change permissions on a physical device.
With a separate permissions file you get a more descriptive language and
potentially the ability to check for some conflicts before making changes.

> > * I don't think there should be any magical default permissions
> > (especially not in drivers); entirely new device types should never appear
> > until permissions are provided by the admin.  I do think the ability to
> > specify default permissions for any number of such devices or for a
> > limited range of such devices would be a good thing.  It would also be a
> > good idea to make it possible for modload to add such permissions (but it
> > should not do so by default).
>
> Why? Note that there is a difference between the device having default
> permissions and the node showing up. In all the devfs proposals I've seen,
> there either has been an explicit hook for policy upload to the kernel
> (the binary file idea I've suggested) or userland daemons (what you're
> proposing), or there could be one (devfs on other nodes, say symlinks). So
> there is a space to say, "don't just add nodes." Thus the act of the
> device showing up (with the despised, uncontrolled default permissions)
> can be easily stopped.

  I think that devices should never appear with permissions unknown to the
administrator.  If default permissions are stored in the driver, a kernel
update can change your device permissions.  You should not need to set an
option for that to not happen.  Furthermore, the kernel does not manage
users and other than root has no business assuming that a particular
number corresponds to a particular user.  There seem to currently be
default entries owned by uucp as well as root.  Updating the devfs should
not be needed frequently nor should it be particularly difficult.  I think
a single global default for unmatched devices (specified in the devfs
config file) that would be very restrictive (no access) would be a good
thing, possibly even a good default.  With that in place if you update
your kerenel and get new devices but forgot to import permissions for
them, you would still see them in /dev and be reminded to set them.

> > * I think the idea of "locator" names needs more thought, or at least
> > more description.  Multiple namespaces raises the possiblity of
> > different names for different means of reference (device file, kernel
> > printed message, sysctl node, ifconfig -a type stuff, etc.), and
> > trying to determine what name is appropriate where and matches what
> > other name(s) could become an easy source of error and confusion.  I
> > haven't noticed any suggested details about how this would work in
> > this thread.
>
> The only locator namespace I've had in mind, and the only one I've
> understood other folks have had in mind, is that of kernel devices. i.e.
> config locators, the things you can put in kernel config files.

  I was a little confused about locators, but not too much (read the first
sentance as WRT devfs).  Devices can have more than one locator, so what I
am most concerned about here is that no part of the kernel refer to a
device without also referring to the cannonical name.  From your message:
http://mail-index.NetBSD.org/tech-kern/2004/11/20/0018.html
I can't tell how you intend to treat device names elsewhere in the kernel.

  I see now that what I have been forgetting is the basic wedge problem:
wd0a no longer exists.  Insetad you have wdN that are disks, and wedgeN
that are wedges; some number of wedges in no particular order are used to
partition this disk (it might be a little more complex and/or different
than that, I don't recall, but that is the basic problem).  I must have
read this twenty times, but until now I didn't connect the dots.

  However, my last point about uniform reference still stands and I have a
strong feeling that a usable cannonical tree is necessary for
administrative sanity.  I think this should still be possible with a
coordinated system of device naming and additional major number use.
I'll look into it more and see if I can come up with something.

Matthew Orgass
darkstar@city-net.com