Re: devfs vs udev, thoughts from a devfs user

[Helge Hafting]

Mike Bell wrote:
> I've been reading a lot lately about udev and how it's both very
> different to and much better than devfs, and with _most_ of the reasons
> given, I can't see how either is the case. I'd like to lay out why I
> think that is.
>
> I keep hearing about how udev has no naming policy in the kenel, while
> devfs has a fixed one and if you don't like it tough. 

One of the weakest arguments - who really cares if the kernel sets some
device names?  Makedev users rarely change those names either, although
they can.  Those rare cases where you need to rename a device so some
stupid binary-only thing can find it is solvable by symlinks.

Devfs is dying because nobody bothers fixing it (and it is believed
to be a big job).  Those who can seems to like udev.  No matter what
virtues devfs may have - arguments are useless unless someone volunteers
to maintain it.  I don't think it will disappear if someone does that and
does it well, but I am sure it _will_ go if nobody does.
A nice concept not yet implemented properly doesn't cut it.

> But udev relies on
> sysfs, which IS naming policy in the kernel. And devfs has devfsd, which
> is a userspace daemon that listens to a kernel-exported filesystem (just
> like udev) and can create whatever /dev layout you want from that, in
> userspace (just like udev). Basically, udev relies on sysfs exporting
> device numbers. Well, imagine for a moment sysfs exported actual device
> files instead of just the numbers you'd need to make a device file (a
> pretty minor change, though not one I'm advocating). What you've got
> there is basically devfs and devfsd, right? Not the same

Interesting idea.

> implementation-wise, obviously, but essentially IDENTICAL concepts.
> Kernel exports device files to a kernel-generated filesystem, user-space
> daemon creates /dev from those with a layout according to your liking.
>
> Meanwhile, devfs (or a devfs-like solution) offer several things which
> udev just can't. Having a special kernel-exported filesystem just for
> /dev means your user-space daemon can see when a program is trying to
> access a device file that doesn't exist yet, 

Devfs can do this, but it is not necessarily a good thing.
I tried it - and it only works if someone tries to look up
a particluar name, such as /dev/dsp.  It doesn't work when someone
does a "ls /dev" to see what devices is there.
A "ls /dev/dsp*" didn't find the multiple soundcards for which
modules weren't yet loaded.

So you can list and see nothing, and still have stuff magically
appear _if_ you know what the name ought to be.  A hairy concept.
Do you know the device name for the second sound device?

The point of this is module users - they can delay module loading
till the module is needed.  Supporting opening of "nonexisting" devices
required a trigger mechanism though - devfsd had to know what module
to load at lookup time.

Non-devfs setups (with or without udev) support a similiar trigger
mechanism for module loading, that is simpler to set up and understand.
And that is a persistend device node.  Plain, simple, and ls sees it too.
Open it and the device is loaded as needed.  And at open time, not
at lookup time.  Load at lookup time might not be necessary, after all.

devfs gave us a /dev uncluttered by nonexisting hardware - now
udev can do that part and some persistent nodes can do the module 
loading part. 

> you can't do that with
> udev and tmpfs. Moreover, it means you've got a functional /dev that
> accurately represents the system regardless of whether the user-space
> daemon is running yet. With udev, you're stuck with a static /dev unless
> udev is running. 

I worried about this too, but notice which way the kernel is going.
"Essential" stuff like parsing the disk partition tables (or getting
a nfs root via dhcp) is being moved out of the kernel and into a
early userspace in initramfs.  Such a thing _must not_ break, so it
is the perfect place to put udev too.  It won't break from mere
misconfiguration because the initramfs isn't on disk but stuffed into
the kernel image where it is safe.  Someone who actually disrupts the kernel
loose anyway.

> This can happen when broken system or doing a fresh
> installation, or if you accidentally break your udev binary. 

Not if it resides in early userspace.  Then you need to break
the kernel image.

> And heavens
> help you if linux ever moves to dynamic device files, that would make a
> static /dev completely unusable. Which would in turn mean that your
> system is unusable unless udev is running. It's not a big problem, but
> myself I find myself using devfs without devfsd for those two reasons
> every once in a while, and in those instances devfs is really nice.
If devfsd ran out of early userspace then you'd never be without that either.

> So the question is, is a devfs-like implementation really unfixable? And
It is fixable, but nobody wants to do it.  They have another solution 
they like better.  Feel free to fix devfs though, then we'll get
choice . . .

Helge Hafting

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/