Re: devfs vs udev, thoughts from a devfs user

[Mike Bell <kernel@mikebell.org>]

On Tue, Feb 10, 2004 at 03:11:19PM -0500, Theodore Ts'o wrote:
> At least some races are inherent to the idea of having a filesystem
> which is mounted on /dev.  At some level, this seems to be your main
> complaint to the udev/sysfs combination --- that you cannot mount some
> particular magic filesystem on top of /dev.  But think about it.  If
> you are having the kernel specify a specific name, and then allow
> devfsd program to override it (but have it magically appear in /dev if
> devfsd is not running) it is very hard to avoid the races, and it
> certainly makes it hard to do anything other than the one sender, one
> receiver model.

OK, but I wasn't talking about overriding. In fact, I was taking it as
read that the devfs-type solution can't override (which it sort of
COULD, but as you say it has races) but would instead have its userspace
daemon create nodes _in addition to_ the kernel created ones, based on
user policy. Or symlinks, whatever the user space daemon wants.

> If instead you have a filesystem which fundamentally must be mounted
> somewhere else, such that there is no question that it can't be
> mounted on /dev, and you have a notifer which tells you what's going
> on --- well, you have the udev/sysfs combination.  

Agreed. 

> You could pontentially do this if you mount the devfs filesystem on
> /devfs, but as near as I can tell, that was just a stalking horse by
> the devfs folks who tried to be all things to all people.  If you're
> going to mount devfs on /devfs, then udev/sysfs does a better job,
> because that's what it's designed to do.

Yes, agreed. If anything, that was one of the points I was trying to
make, that udev/sysfs is similar in concept to devfsd with devfs mounted
somewhere other than /dev (please nobody tell me how sysfs and devfs are
different, I know. I meant for the purposes of the udev/devfs user space
programs, they're fulfiling the same purpose. Getting a major and minor
from the kernel to the userspace daemon by creating a file on a
kernel-generated filesystem.)

What I would like to see is a kernel generated /dev with
kernel-specified paths. A userspace daemon, whether you call it udev or
devfsd, would then manage alternate (in addition to, not instead of)
naming schemes according to the sysadmin's whim and permissions of
device nodes and other things that just don't make sense to do in kernel
space.