[Linux-Biella] udev vs devfs

[Paolo Ciarrocchi]

2009/4/4 Paolo Ciarrocchi <paolo.ciarrocchi a gmail.com>:
>>> immagino che se ne sia parlato..
>>>
>
> Per mesi.
> E la sua implementazione è nel kernel, non c'è modo di scegliere
> all'avvio il vecchio "approccio".
>
> Quello che ora state discutendo non è tanto però in problema di udev
> ma di approccio della distribuzione.

Per essere ancora più chiaro, cito l'autore di udev:

The Problems:
 1) A static /dev is unwieldy and big.  It would be nice to only show
    the /dev entries for the devices we actually have running in the
    system.
 2) We are (well, were) running out of major and minor numbers for
    devices.
 3) Users want a way to name devices in a persistent fashion (i.e. "This
    disk here, must _always_ be called "boot_disk" no matter where in
    the scsi tree I put it", or "This USB camera must always be called
    "camera" no matter if I have other USB scsi devices plugged in or
    not.")
 4) Userspace programs want to know when devices are created or removed,
    and what /dev entry is associated with them.

The constraints:
 1) No policy in the kernel!
 2) Follow standards (like the LSB)
 3) must be small so embedded devices will use it.


So, how does devfs stack up to the above problems and constraints:
  Problems:
    1) devfs only shows the dev entries for the devices in the system.
    2) devfs does not handle the need for dynamic major/minor numbers
    3) devfs does not provide a way to name devices in a persistent
       fashion.
    4) devfs does provide a deamon that userspace programs can hook into
       to listen to see what devices are being created or removed.
  Constraints:
    1) devfs forces the devfs naming policy into the kernel.  If you
       don't like this naming scheme, tough.
    2) devfs does not follow the LSB device naming standard.
    3) devfs is small, and embedded devices use it.  However it is
       implemented in non-pagable memory.

Oh yeah, and there are the insolvable race conditions with the devfs
implementation in the kernel, but I'm not going to talk about them right
now, sorry.  See the linux-kernel archives if you care about them (and
if you use devfs, you should care...)

So devfs is 2 for 7, ignoring the kernel races.

And now for udev:
  Problems:
    1) using udev, the /dev tree only is populated for the devices that
       are currently present in the system.
    2) udev does not care about the major/minor number schemes.  If the
       kernel tomorrow switches to randomly assign major and minor numbers
       to different devices, it would work just fine (this is exactly
       what I am proposing to do in 2.7...)
    3) This is the main reason udev is around.  It provides the ability
       to name devices in a persistent manner.  More on that below.
    4) udev emits D-BUS messages so that any other userspace program
       (like HAL) can listen to see what devices are created or removed.
       It also allows userspace programs to query its database to see
       what devices are present and what they are currently named as
       (providing a pointer into the sysfs tree for that specific device
       node.)
  Constraints:
    1) udev moves _all_ naming policies out of the kernel and into
       userspace.
    2) udev defaults to using the LSB device naming standard.  If users
       want to deviate away from this standard (for example when naming
       some devices in a persistent manner), it is easily possible to do
       so.
    3) udev is small and is entirely in userspace, which
       is swapable, and doesn't have to be running at all times.

Articolo completo qui:
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://mypage.vodafone.it/