[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

udev device naming policy concerns

  I'll just start by quoting Marco d'Itri (the udev maintainer) notes
 about this subject from README.Debian:

 > Naming policy
 > ~~~~~~~~~~~~~
 > The plan, so far, is to have the default configuration create devfs-like
 > devices. Compatibility symlinks will be created for common devices for
 > which the new names are still not used by defaults by programs, but the
 > goal is to remove most of these links.
 > If you think more aliases are needed or some aliases should be removed
 > please discuss this with the udev debian maintainer.
 > Feel free to submit an additional config file with more aliases or one
 > with only old style devices.

  (For those who haven't used neither devfs nor udev, this means that,
 say, the first serial console device will be /dev/tts/0, probably with
 an interim compability symlink at /dev/ttyS0.)

  First of all, devfs is considered obsolete by the upstream kernel
 maintainers.  The devfs naming style (or devfs itself, for that matter)
 has, as far as I know, never been the default way of of handing /dev,
 nor has it been made the standard by any major distribution except
 Gentoo.  If I recall correctly, devfs went straight from being marked
 as EXPERIMENTAL to OBSOLETE in the kernel config.

  That we should adopt this obsolete naming scheme as the default concerns
 me;  I do not wish to see such radical decisions affecting the very core
 of our distribution being made on a whim by individual maintainers.  udev
 seems overwhelmingly likely to become the default way of handling /dev on
 GNU/Linux as it's being endorsed by the upstream kernel maintainers and,
 well, is pretty fucking neat, IMHO.  I'll wager we'll be using it as the
 default for Sarge+1.

  I'll also wager that if we go with the devfs naming style we'll be the
 odd man out.  The Linux kernel itself, and the upstream udev sources,
 names the devices the standardized (ttyS0) style and doesn't, as far as
 I know, have -any- plans to change that.  The same goes for Red Hat, and
 probably the most of the other major distributions.  The only one I know
 of that's adopted devfs as the default is Gentoo, and according to their
 site they're about to ditch devfs (and I believe their udev package does
 the exact oposite of ours and creates compability symlinks for those
 already using the devfs names, and that they mean to get rid of it
 completely after their users have had some transitioning time).

  That we should decide to go in the oposite direction of what all the
 other distributions (including the direction we ourselves are going at
 the moment) and the upstream Linux folks go, is in my opinion
 objectionable enough and should be decided in plenum (or in the absense 
 of a clear consensus, the tech-ctte).

  That one of our goals shall be to eventually have changed all of our
 packages to use the devfs-style naming style exclusively and have removed
 the symlinks from the standard locations, thus having rendered ourselves
 incompatible with every other major distributor (and that includes most
 upstream sources that use device nodes directly), is absolutely
 ludicrous.  Not only is it a unrealistic goal, but I fail to see *any*
 advantage accomplishing it will make.

  When I requested a rationale for the change from Marco on IRC, the one
 I got was, quote: "it's useful", and: "you can install your own rules
 file anyway if you don't like them".  While I agree that the devfs
 naming style has some advantages over the standard naming style
 (particulary regarding SCSI hard drives), the drawbacks on making it
 the default surmount those by far.  I strongly feel that our udev package
 shouldn't deviate from the rest of the world.  Those who require the
 advantages non-standard device naming give should be the ones using
 non-standard udev rules files.

  Marco asked me to voice my concerns here on the list instead of
 continuing the discussion on IRC, so, well, here they are.  Comments
 are welcome.

Tore Anderson

Reply to: