[Gllug] Re: Alcatel SpeedTouch on Slackware 10

[Nix]

On Sat, 19 Nov 2005, Doug Winter suggested tentatively:
> I sync with a tungsten with no trouble whatsoever, and I don't have to
> go anywhere near udev.  In fact, udev is afaik not recommended in
> general, and is deprecated in newer kernels.

You're thinking of devfs, udev's predecessor. Under devfs, the /dev tree
was a unique kind of filesystem (hence the name) in which devices
appeared and disappeared by kernel fiat. While this seemed like a neat
idea at the time it had numerous huge problems:

- the names and permissions of the devices were wired into the kernel
  (udev uses a userspace file and arbitrary programs to do this: the
  `u' in `udev' stands for `userspace', after all)
- the default names and permissions were deeply weird (although the
  `standard set' was also available)
  (udev has a rules file which can make it use those weird sets too,
  for those people who've come to rely on it)
- because the filesystem had no disk backing, preserving permissions
  and ownership changes was really annoying, involving a separate
  daemon (devfsd) with no other purpose in life
  (udev can put its devices on anything; it's often a tmpfs with no
  disk backing, but it can be an ordinary disk-backed filesystem
  if you want. Voila, no special support needed for persistence
  at all.)
- the *kernel* created and deleted those device files, which is
  normally a complete no-no; only filesystems like /proc and /sys
  normally have that sort of thing happening in them, and files in
  those filesystems are not expected to be held open for a long time.
  (Normally the kernel should only create, remove, read or even open
  files when asked to do so on behalf of some specific process, e.g.
  by that process calling open()).
  Device files *are* expected to be held open, which makes the idea
  of a bit of the kernel removing them annoying; what if the file
  vanishes while the kernel is rename()ing the directory tree holding
  them, for instance?
  (udev, again, plays with ordinary filesytems, and creates and removes
  device nodes using all the normal userspace mechanisms, so all this
  crap just goes away.)

The perceived flaws in devfs led to a lot of bickering when devfs was
proposed for inclusion, with famously acerbic kernel demigods like Al
Viro describing it as `unfixably racy' and protesting its inclusion
strongly. It got in eventually, in the 2.4 period, because there was no
better alternative... but then its maintainer (Richard Gooch) dropped
off the face of the Earth and nobody else could stomach his code, and
once udev was invented, in the 2.6 period, devfs had the unique
experience of moving directly from EXPERIMENTAL to OBSOLETE without ever
being recommended. Now it's removed entirely with very few complaints
except from some embedded people who dislike the 600Kb+ memory hit of
the /sys filesystem that udev needs.

udev can do everything devfs can do, and far more flexibly, with one
exception: devfs had a trick whereby merely *accessing* some device
that you didn't have a module loaded for would load the module,
*even if the device didn't exist*. So opening /dev/dri/0 would load
the DRI drivers *even if /dev/dri0 didn't exist before you did that*.
This is not exactly a terrible loss (although some people claimed
that it was).

-- 
`Y'know, London's nice at this time of year. If you like your cities
 freezing cold and full of surly gits.' --- David Damerell

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug