While earlier this year some work was done to eliminate libxc's
creation of nodes under /dev (as in some cases it actually got
things wrong), I just found that tapdisk2 does exactly the same.
While I'm not currently aiming at removing this code, I want to
at least suggest some adjustments to the provided rules file.
First of all, the present rule
KERNEL=="blktap[0-9]*", NAME="xen/%k"
matches both blktap1's devices and blktap2's ring devices,
resulting in whoever comes last replacing what was there
before (e.g. a tap2:aio: attach will replace bltap1's
/dev/blktap0 [i.e. the main control device] with the ring device
of the new virtual disk). Therefore we should add a subsystem
qualifier there.
Second, at some udev versions default to using 0660 as the
permissions on nodes it creates. The kernel (with devtmpfs)
defaults to 0600, and hence I'd suggest to also make this
explicit in the rules.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
--- 2010-08-12.orig/tools/hotplug/Linux/xen-backend.rules 2010-08-12
08:17:22.000000000 +0200
+++ 2010-08-12/tools/hotplug/Linux/xen-backend.rules 2010-09-09
15:58:15.000000000 +0200
@@ -7,6 +7,10 @@ SUBSYSTEM=="xen-backend", KERNEL=="vif-*
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"
-KERNEL=="pci_iomul", NAME="xen/%k"
+SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
+SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k",
MODE="0600"
+KERNEL=="blktap-control", NAME="xen/blktap-2/control", MODE="0600"
+KERNEL=="gntdev", NAME="xen/%k", MODE="0600"
+KERNEL=="pci_iomul", NAME="xen/%k", MODE="0600"
+KERNEL=="tapdev[a-z]*", NAME="xen/blktap-2/tapdev%m", MODE="0600"
SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add",
RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
udev-rules.patch
Description: Text document
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home