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.