Re: small devfs patch for 2.5.65, plan to replace /sbin/hotplug

Kevin P. Fleming
2003-03-21T20:35:58Z

Adam J. Richter wrote:
> I believe that the only change in this version of devfs is
> moving the code to invoke the user level devfs_helper program to a
> separate file, fs/devfs/notify.c. This change will simplify a future
> code shrink inspired by David Brownell's suggesting that I think about
> unifying hotplug with devfs. In the future I would like to lift
> fs/devfs/notify.c out of devfs so that the code that currently invokes
> user level helpers for hot plug events can be replaced with two calls
> to a renamed devfs_event() on
> /sys/bus/<bustype>/devices/<bus#>/<whatever>, one for insertion and
> one for removal.

Are you still considering smalldevfs for 2.6 inclusion? If not, then I'd like to
discuss with you (and Greg KH) the possibility of just eliminating devfs
entirely, and moving to a userspace version that is driven entirely by
/sbin/hotplug.

There are already adequate hotplug events generated in 2.5.65+ to create and
remove all necessary /dev entries, other than /dev/console (and that gets
created by the initramfs being unpacked). If the devfs concept of "devfs_only"
(no major/minor access to device drivers) is truly gone (as it appears to be),
then the userspace variant of devfs would be quite simple: process the hotplug
event and read the appropriate information out of sysfs to get the dev_t for the
device, then follow user-specified policies to create /dev entries.

Unless I'm missing something obvious, "devfs" could be just a synonym for a
specific tmpfs instance, with no built-in behavior at all. At initramfs unpack
time it would be mounted on /dev, /dev/console would be created, and then
/sbin/hotplug would create/remove entries as the drivers to their thing.

When the real root filesystem gets mounted, devfs could then be mounted again on
the new /dev (just like devfs now) and everything's running smoothly.