On 2004-11-29 wrstuden@NetBSD.org wrote:
> On Sun, Nov 28, 2004 at 01:15:11AM -0500, der Mouse wrote:
> > > My thoughts were that, with the binary file idea, we have explicit
> > > atime, mtime, and ctime fields.  When the node gets updated, we note
> > > the change and mark the internal entry dirty.  [...]
> >
> > Now, I have a question.
> >
> > At this point we are inventing a naming scheme for devices (so that
> > changes of, eg, mode, or mtime) can be associated with the same device
> > on subsequent reboots, stored somewhere, and read back next boot.
> >
> > At this point, I feel forced to ask: what benefits does this devfs
> > offer over simply redesigning device nodes to use this new naming
> > scheme instead of the <major,minor> naming scheme we've been using so
> > far?  (I am not claiming there are no such benefits.  I'm just trying
> > to compare devfs against "simply" redesigning device special files,
> > which latter would automatically preserve many of the things we've had
> > to worry about devfs preserving, such as traditional semantics for
> > calls like chown and chmod.)
>
> 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.

  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).

* 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.

* In general, allowing dynamic behavior to be constrained by userland
programs (and not just static files) seems like a good thing to me, as
long as the interaction of such programs is designed to do so safely.

* 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).

* I think the idea of "locator" names needs more thought, or at least more
desciption.  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.

* I think I would prefer a single cannonical namespace from the kernel
perspective and make it possible to use locators to lookup cannonical
device names.  It should be possible (and IMO is desireable) to implement
this lookup method generally to support "locator" identification in
userland.  This mechanism must ensure that the target of a sccessful
"locator" lookup will not become something else until all entities that
referenced it by means of locators are no longer using that reference.
This could possibly be done with procfs, separate from devfs.


Matthew Orgass
darkstar@city-net.com