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

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Thu, Mar 11, 2010 at 2:49 AM, Jochen Kunz 
<jkunz%unixag-kl.fh-kl.de@localhost> wrote:
> 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...

Sounds interesting, but hard to grasp your view exactly.  Examples help.

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

chmod(2) / chown(2) are OK.  devfsd(8) also needs to track rename(4)
done in /dev.  (I never do like that, but people want...)

Masao