Re: devfs vs udev, thoughts from a devfs user

[Timothy Miller]

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.

-
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/