Xen, Linux and udev

udev is the device manager for the Linux 2.6 kernel series. Primarily, it manages device nodes in /dev. It is the successor of devfs and hotplug, which means that it handles the /dev directory and all user space actions when adding/removing devices, including firmware load. The system is divided into three parts:

The library libsysfs, that allows access to device information (dropped since version 080)
The daemon udevd, in user space, that manages the virtual /dev
The administrative command udevadm for diagnostics

When trying to boot Ubuntu 9.04 with 2.6.18.8 Xen modified kernel that comes with default Xen sources the following error ocured (look at /var/log/syslog file for the boot log):

Oct 25 22:52:26 Express2 kernel: udev: starting version 141

Oct 25 22:52:26 Express2 kernel: udev: deprecated sysfs layout; update the kernel or disable CONFIG_SYSFS_DEPRECATED;
 some udev features will not work correctly

My current image distribution udev version is 141. In order to get udev, distribution and current kernel version you can do the following:

matmih@Express2:~$ udevadm info -V ; cat /etc/issue ; uname -a
141
Ubuntu 9.04 \n \l
Linux Express2 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

This means that the kernel version that comes with xen 3.4.1 may be too old for my Ubuntu. As you can see from the above the original modified kernel (with Ubuntu patches) was based on a 2.6.28 version.

But let’s take a short look at how custom Linux Dom0 makes use of udev services. After you compiled xen 3.4.1 you can take a look in:

matmih@Express2:~/Work/xen-3.4.1$ ls dist/install
boot  etc  lib  usr  var

Here is it where xen build system will place all the binaries and configuration files needed to be deployed in the dom0 image. The udev stuff can be found in etc/hotplug and etc/udev directories.

Lets take a look at what custom udev rules xen system is adding to the Linux Dom0 Image:

matmih@Express2:~/Work/xen-3.4.1/dist/install/etc$ cat udev/xen-backend.rules
SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
SUBSYSTEM=="xen-backend", KERNEL=="vif*", ACTION=="online", RUN+="$env{script} online"
SUBSYSTEM=="xen-backend", KERNEL=="vif*", ACTION=="offline", RUN+="$env{script} offline"
SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
KERNEL=="evtchn", NAME="xen/%k"
KERNEL=="blktap[0-9]*", NAME="xen/%k"
matmih@Express2:~/Work/xen-3.4.1/dist/install/etc$ cat udev/xend.rules
SUBSYSTEM=="pci", RUN+="socket:/org/xen/xend/udev_event"
SUBSYSTEM=="scsi", RUN+="socket:/org/xen/xend/udev_event"
#SUBSYSTEM=="net", KERNEL!="vif[0-9]*.[0-9]*|tap[0-9]*.[0-9]*", RUN+="socket:/org/xen/xend/udev_event"

We can see that for all xen-backend devices, such as tap or vscsi certain scripts are run for each specifice driver event. As well all pci and scsi device events are sent through a named socket org.xen.xend to be processed by the xend daemon, in the same format the kernel uses for the event – usually a netlink message.

For example the udev rule line:

SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"

calls, for every tap* block device added to a virtual machine (a partition backed by a local filesystem file – blktap device functionality) /etc/xen/scripts/blktap bash script which checks the xenstore database if this file on the local filesystem hasn’t been already assigned to another virtual block device or if the access rights on the file are ok. If the script fails the udev system does not allow the file to be used (the device operation is forbidden).

udev的配置文件：/etc/udev/udev.conf

udev_log="debug" 默认为err

udev的日志文件： /var/log/messages

http://www.2virt.com/blog/?p=23