Messages in this thread | | | Date | Tue, 10 Feb 2004 17:49:04 -0800 | From | Mike Bell <> | Subject | Re: devfs vs udev, thoughts from a devfs user |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |