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

-------- Forwarded Message --------
From: Scott James Remnant <scott@canonical.com>
To: Ubuntu Development <ubuntu-devel@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

--
Ubuntu-news-team mailing list
Ubuntu-news-team@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-news-team