Re: devfs vs udev, thoughts from a devfs user

Timothy Miller
2004-02-10T20:11:08Z

Please forgive me for stepping into this conversation so late...

Mike Bell wrote:
> On Tue, Feb 10, 2004 at 12:52:51PM -0500, Chris Friesen wrote:
>
>>What names would you use for your device files? This is the key
>>difference. With udev it gets a notification that says "I have a new
>>block device", it then looks it up, applies the rules, and creates a new
>>entry. The whole point is to move the naming scheme into userspace for
>>easier management.
>
>
> Why does it make management easier to have no predictable name for a
> device?
>

What's unpredictable about it? udev can apply exactly the same rules
that devfs uses, thereby coming up with the same names. In that limited
case, the advantage to udev is to move code out of the kernel. Not only
does that shrink the kernel, but it moves policy that affects user space
into user space.

If udev had a "devfs" mode where it used a ramdisk for device nodes, and
it produced exactly the same names as devfs, would you be happy with it?

Any device node you needed would have been generated well before you
needed it, and being a filesystem node, it's no slower to actually USE
the device than devfs, and you'd get all the same behavior you had
before. The ONLY difference is that the code isn't in the kernel.

You have the further advantage, for the embedded people, that you can
eliminate udev, and create static device nodes, without having to modify
the kernel in any way.

For the typical case, udev COULD produce the same device names as devfs,
completely addressing your "predictability" issue. It would be
PERFECTLY predictable. But it has the additional advantage of being
able to keep a database in a file that it uses to also make device names
CONSISTENT. Thus, if you attach a USB device and then remove it and
then attach it again later, udev has a simple way to compare that device
against its history of known devices and give that device again exactly
the same name. Can devfs do that? If so, where does it keep its history?

>
>>You could have the kernel export a simple devfs with a hardcoded naming
>>scheme based on similar ideas as what is in sysfs (which would then make
>>sysfs and the daemon optional for tiny embedded setups), but the only
>>advantage over just exporting the information in sysfs is to save a few
>>bytes at the cost of yet another filesystem to maintain.
>
>
> I think the space savings are a pretty good reason alone. Add to that
> the fact I think devfs would be a good idea even if it cost MORE
> memory... You can mount a devfs on your RO root instead of needing to
> mount a tmpfs on /dev and then run udev on that. A devfs gives
> consistant names for devices in addition to the user's preferred
> user-space dictated naming scheme. A devfs means even with dynamic
> majors/minors, even if you have new hardware in your system, your /dev
> at least has the devices it needs.

How does devfs save space? Device node information has to be stores
SOMEWHERE. Whether that's in filesystem nodes or in datastructures in
the kernel that are dynamically made to LOOK like device nodes, you
still need to take up memory.

As for dynamic major/minor numbers, I'm not sure how udev precludes
that. The fact that udev might keep minor numbers from changing over a
reboot doesn't matter. Dynamic major/minor numbers just means that they
can be arbitrary.