>On Sun, 4 Jan 1998, Andrea Arcangeli wrote:
>> On Sat, 3 Jan 1998, Richard Gooch wrote:
>>
>> >The reason my scheme doesn't depend on kerneld is that if a driver is
>> >built-in/loaded by a boot script, the /dev entries for that driver are
>> >registered in the startup code. So, on a system like mine where all
>> >drivers are either built-in or automatically installed by a boot
>> >script, /dev would be fully populated. An attempt to open(2) an entry
>> >in /dev which did not exist would cause devfs to return -ENODEV
>> >because kerneld isn't running.
...and if kerneld is running kerneld will "mknod" the device in /devfs.
This is what I don' t agree and I take as wrong.
>> - You could implement that more easily without use kerneld.
>Yes, but then we don't have module autoloading.
I am not talking about modules. The open(2) implementation that Richard
proposed in the paragraph above is whole related to static device and not
only module.
>> - I think this is totally wrong for programs or people that check in /dev
>> for a device before try to open it, or at least is a mess.
>WHAT!!! The whole point of a virtual devfs is that you can do a "ls /dev"
>to see what devices are currently accessable. And most actions on a divice
>start with a call to open() (or mount()).
Richard in the paragraph I quoted, proposed a devfs implementation that
don' t show what devices are currently accessible, but only the ones
opened(2).
>> - If you want to make something useful, your devfs must be populated from
>> _all_ kernel devices at boot with 600 permission and it must not remove
Obviously I want to mean _all_ and __only__ kernel devices linked or
insmodded with the kernel.
>> device entry for some reason. It can add/remove devices from the
>> filesystem only when you load/unload a kernel module.
>NO! We want only divices that are acatually on the system to show up in
>/dev. That is the main selling point of a devfs.
You should read the quoted mail before reply.
>> - Since devfs should be a virtual device that forget permission and
>> ownership at reboot (or after module unload) it will make the life hard
>> and less efficient in the rcS.d scripts. I' d like to chown directly
>> /dev/devname on ext2, instead of change a bootup script or adding the
>> line "option modname chmod 644 /dev/modname; chown ..." in /etc/conf.modules.
>> I don' t like something of only virtual.
>OK, so write a little c proggie that stat()s each file in /dev and restores
>them apon boot. Problem solved.
I know but I am a bit conservative when all just works perfect and
efficient...
Andrea[s] Arcangeli