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

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

On Wed, Mar 10, 2010 at 4:54 PM, Jochen Kunz 
<jkunz%unixag-kl.fh-kl.de@localhost> wrote:
> On Wed, 10 Mar 2010 11:53:43 +0900
> Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:
>
> [device node ownership and modes on devfs]
>> Is it acceptable for you to do such things by some layering?
> Anything else but "chown jkunz.users /dev/ttyU0" is awkward to me.
> So what ever solution for this problem is introduced (udevd,
> rc.script, ...), I have to learn a special way to configure device
> node ownership and modes on devfs.
>
> There could be some devd(8), that listens for ownership and modes
> on devfs and stores it on disk. At next boot it could reconstruct
> ownership and modes. But this looks a bit fragile to me.
>
>> > The Linux devfs solved this problem with an init-script, that changed
>> > ownership and modes after each reboot. Looked a bit awkward to me when
>> > I had to deal with it.
>> A bit?  I thought udevfs's config file is totally inacceptable for
>> missiong critical embedded purposes.  Why do we have to learn a new
>> syntax to configure only a few device file permissions?
> I talked about the long gone Linux devfs, not udev. But it doesn't
> matter. Anything else then chmod(1) and chown(8) needs to be learned.
> So it doesn't matter what new stuff I have to learn to get it done.

Fair enough.

After some thinking, providing "traditional" view and persistent bits
turns out to be not that difficult.

/dev has a few reserved directory (like /dev/id).  You have no freedom
there.  Any access other than that goes to devfsd.  It has knowledge
equivalt to sys/arch/*/conf/majors.* as reference.  And it tracks
mknod(2), rename(2), etc per-mount point.

When you do mknod(/dev/wd0a); rename(/dev/wd0a, /dev/woah0a);
open(/dev/woah0a), devfsd resoves it by using DBs and converts it to
something like /dev/default/wd0a and pass it back to kernel.

You have to shutdown cleanly, otherwise you lose DB.

Initial mount needs some thought.

> BTW: My dayjob is to programm an embedded system running Linux.
> A (small) part of my work is to fight with udevd. And those systems
> are used in mission critical applications.

Are you happy about that? :)

Masao