[Fwd: udevadm, and why you should stop what you're doing]

[James Westby]

-------- Forwarded Message --------
From: Scott James Remnant <scott at canonical.com>
To: Ubuntu Development <ubuntu-devel at lists.ubuntu.com>
Subject: udevadm, and why you should stop what you're doing
Date: Thu, 22 Jan 2009 21:06:48 +0000

There's a bit of a meme going around that it's safe to call udevadm (or
its symlinks like udevtrigger/udevsettle) from package maintainer
scripts without worrying about it.

I'm afraid to tell you that it isn't.


Here's a quick guide to what is safe to call:


  I want to find out information about a device.

	udevadm info

	This is safe to call, and in recent releases
	returns all information; combining both the udevdb and the
	kernel uevent info.

	It's even better to use libudev if you're writing code ;-)


  I've built a module, and want to see if it's needed for anything on
  the system.

	modprobe

	*NOT* udevadm trigger.  I just filed a Critical bug against dkms
	for this.

	Just modprobe it.  If no devices are claimed, then the module
	will not be loaded and modprobe will return an exit code.  If
	devices are claimed, it'll return 0.

	You need to depend on module-init-tools, of course; because
	you're probably going to call things like depmod first


  I've installed udev rules and want udev to do something about it.

	udevadm trigger --action=change

	*and* Depend on udev (you can't udevadm when udev is
	unconfigured)

	The action argument is of utmost importance.  Without it, the
	kernel will tell udev to treat all devices as *NEW*.  This will
	have lots of side-effects you are probably not expecting.

	"change" is completely safe.  It tells udev just to refresh
	devices, and make sure everything's as it should be.

	(This solves the network manager double-interface bug, the "my
	 disk is corrupt until after reboot" bug, etc.)


  I've loaded a module, or called an ioctl(), or poked the kernel in
  some other way, and I want udev to finish processing it.

	udevadm settle

	*and* Depend on udev.

	There is no need for a trigger call; udevd is running, it'll get
	the uevents from the kernel anyway.  Trigger would just resend
	them (along with uevents for the entire rest of the system
	-which will have dangerous side-effects).

	settle waits for udevd to finish processing any uevents queued
	by the kernel when it is called.

	This allows you to ensure the device node is created, or any
	programs udev runs like vol_id are no longer running.

	There are conditions it does not wait for:

	- if you load a module for a bus, it won't wait for all devices
	  on that bus to show up -- it will only wait for the bus
	  to appear under /sys/bus 

	  there's no such things as "probe completion" for just about
	  any bus you can name, your software simply needs to deal with
	  the fact that devices may show up at any time

	- if you load a module containing a device driver, the driver
	  will claim all devices but the "class device" may not appear

	  e.g. loading a network card module doesn't mean that eth0 will
	  appear

	  it means that the pci device is claimed and the driver
	  initialised; it may be calling out for firmware, or performing
	  asynchronous initialisation of some kind

	  the class device will show up later, or may not show up at all

Scott