At Fri, 12 Mar 2010 20:22:25 +0100, Manuel Bouyer <bou...@antioche.eu.org> wrote: Subject: Re: (Semi-random) thoughts on device tree structure and devfs > > On Thu, Mar 11, 2010 at 05:54:11PM -0500, Greg A. Woods wrote: > > Indeed -- I do agree with that much at least! > > > > I've had diskless systems running for a long while now (since 2003) > > where /dev is created by init(8) on every boot (by running > > /sbin/MAKEDEV, as I've renamed it). > > > > In the extremely rare cases where I've wanted to change permissions or > > similar on a device node I can just use the normal commands: > > > > chmod 666 /dev/tty001 > > > > and if I want to make such a change persistent across boots I just add > > that exact same command to /etc/rc.local. > > > > There's no magic needed. > > > > I think the only key feature necessary is that devfs handle the normal > > permissions and ownership changes, but to do so of course with no more > > persistence than tmpfs, md. or mfs. > > This wouldn't work very well for hot-plug devices. > As I understand it, nodes would be created at plug time, and removed at unplug > time (correct me if I'm wrong). So you would need to run you chmod > when your e.g. USB device is plugged (which is also the time at which you > know where it will how up in the device space).
Hmmm.... well, we have had "hot plug" devices of a sort ever since 1.6
or earlier (when I began using MFS /dev).....
The only magic trick there is to be able to predict all the possible
major and minor numbers at the time you write your MAKEDEV script, or at
least be able to update that script as necessary. In the past this has
been sufficient, eg. with SCSI probe and scan detecting new devices.
However even that kind of magic really isn't truly necessary.
Indeed without devfs it could be as easy as the kernel to simply
spitting out a message saying that "a device at major N, minor Y" was
available to be used (when it was detected), and then leave it entirely
up to the user, or some agent of the user (eg. a script monitoring for
such messages), to run "mknod" as appropriate, and perhaps adjusting
permissions and ownerships at the same time, possibly even updating
/etc/MAKEDEV.local. In fact I've wanted the kernel to tell me what
major/minor number(s) to use for new SCSI devices, though to some extent
the way MAKEDEV is written to use unit numbers, it works well enough.
Obviously there are other ways for the kernel to notify userland of such
events as device attach/detach besides having a script monitor
/dev/console output or kernel syslog messages. Perhaps kqueue()
monitoring /dev itself is sufficient, though perhaps then only for a
"flat" file tree in /dev.
So, with a devfs implementation that creates the new /dev file node
automatically, the agent script could still be responsible for changing
permissions and ownerships as desired.
I.e. no magic for persistence of filesystem metadata is necessary in
devfs so long as there are ways to monitor for and handle events that
indicate changes have happened in the live state of devfs filesystem.
--
Greg A. Woods
Planix, Inc.
<wo...@planix.com> +1 416 218 0099 http://www.planix.com/
pgpwkBzlUcDyn.pgp
Description: PGP signature
