Re: (Semi-random) thoughts on device tree structure and devfs

[Jochen Kunz <jkunz%unixag-kl.fh-kl.de@localhost>]

On Wed, 10 Mar 2010 10:22:40 -0500 (EST)
der Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> With that in mind, I'd say that the more radical Uebayashi-san's devfs
> is, the less like past (failed) attempts at devfses it is, the more
> likely it is to turn out to be a better way.  Eliminating (this use of)
> dev_t is an example.
Seconded. If you rework it, do it thoroughly. Wipe everything and start
by zero.

Somthing else comes to my mind: Kernel configuration and devfs
configuration interact closely. E.g. you can give the device
enumeration order in the kernel configuration by "nailing down"
devices. Now those symbolic kernel devices like com(4) need to be
assigned to a device node name in /dev.

Why separate those two? There should be a single configuration file
that configures kernel options like what device to search where and
what device node to assign to it. (+ permissions and ownership etc.)
This file is used to get the kernel default configuration at compile
time. Now this file should be passed to the kernel at boottime
optionally. Thus makeing the kernel reconfigurable at reboot. In
addition the in-core version of that file must be runtime alterable.
This way you can en-/disable device drivers at runtime, probably
resulting in the (un)load of a kernel module and creation or delition
of device nodes in /dev. The current kernel configuration can be dumped
to a file and passed to the kernel at next boot...

If you chmod(1) or chown(8) a device node in /dev, devfs updates the
in-core kernel configuration as chmod(2) and chown(2) get down to devfs.
At (clean) reboot kernel configuration gets dumped and reloaded.
Et voila, devfs with persistent permissions without a devfsd(8).
-- 


tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/