First try at improving hal's device mapper support
David Zeuthen
david at fubar.dk
Fri Dec 31 06:15:46 PST 2004
On Wed, 2004-12-22 at 21:22 +0100, Sjoerd Simons wrote:
> Hi,
>
> I've been playing around to get hal to recognize dm devices in a somewhat
> nicer way. For this i've patched device mapper itself to put links in sysfs
> to the backend device.
>
Interesting,
> So for example the encrypted partition on my usbstick looks like this:
> $ ls -l /sys/block/dm-0
> -r--r--r-- 1 root root 4096 Dec 22 19:01 dev
> lrwxrwxrwx 1 root root 0 Dec 22 19:01 device0 -> ../../block/sdb/sdb2/
> -r--r--r-- 1 root root 4096 Dec 22 19:01 range
> -r--r--r-- 1 root root 4096 Dec 22 19:01 removable
> -r--r--r-- 1 root root 4096 Dec 22 19:01 size
> -r--r--r-- 1 root root 4096 Dec 22 19:01 stat
>
> And when merging various partitions on it together
> $ ls -l /sys/block/dm-1
> -r--r--r-- 1 root root 4096 Dec 22 20:30 dev
> lrwxrwxrwx 1 root root 0 Dec 22 20:30 device0 -> ../../block/sdb/sdb4/
> lrwxrwxrwx 1 root root 0 Dec 22 20:30 device1 -> ../../block/sdb/sdb3/
> lrwxrwxrwx 1 root root 0 Dec 22 20:30 device2 -> ../../block/sdb/sdb2/
> lrwxrwxrwx 1 root root 0 Dec 22 20:30 device3 -> ../../block/sdb/sdb1/
> -r--r--r-- 1 root root 4096 Dec 22 20:30 range
> -r--r--r-- 1 root root 4096 Dec 22 20:30 removable
> -r--r--r-- 1 root root 4096 Dec 22 20:30 size
> -r--r--r-- 1 root root 4096 Dec 22 20:30 stat
>
> So we have most of the needed info for hal. The only that is really still
> needed is the name of the dm device (as tools need that to configure it).
>
> Now for the bad things. As can be seen in the second example, a dm device can
> have multiple backing device. But there is no way to express multiple parents
> in hal.
>
> Furthermore when setting up a dm device, first the device itself is created.
> Which causes the hotplug event. After that a mapping from the dm device to
> the target device(s) is created (and thus the deviceX symlinks), but that
> doesn't generate any events. And also the mapping can change during the dm
> device's lifetime (again without kernel events). Maybe this would fall inside
> the kernel-userspace event stuff that has been added for kernel 2.6.10? Any
> kernel people around that know about that :)
>
> Attached are a patch for the kernel to create the symlinks in sysfs and one
> for hal to use that to get the parent. The hal patch sleeps for 2 seconds
> which i long enough to have the mapping setup when using cryptsetup, but
> that's ofcourse not the right way to do it(tm).
>
I'm not sure we will need much more than a way to determine that
e.g. /dev/dm-0 corresponds to the device_name given by dmsetup/
cryptsetup since it is feasible to assume that the tools setting up the
device mapper devices can use names encoded in a way that enables hal to
infer the backing devices.
1. for crypto we will assume that the name is sesame_crypto_<sesame-
uuid> and we can match that against the device object with that
appropriate volume.crypto.sesame.uuid property.
2. for LVM2 we should have similar volume.lvm2.* properties that include
the LVM2 UUID (such a number does exist) and we just decide on a naming
scheme to use. In addition we could create hal device objects of
capability 'storage' as a fake parent - that will also give us dedicated
icon for the drive in e.g. gnome-vfs.
Thus, in my view, basically, all we need is the kernel to give us the
name associated with a device mapper target, but I'm afraid that the
kernel doesn't even store this today.
So, I think it would be useful to talk to the device mapper people to
make dmsetup not create that device node and instead provide an ioctl
and make udev create the symbolic links for backwards compatibility.
With all the nasty asynchronous things that will entail for existing
users of dmsetup - long live the new asynchronous driver model I
guess :-)
Until that happens we may have to live with hald checking
that /dev/mapper/device_name has the same major/minor as the newly
arrived /dev/dm-0, /dev/dm-1. With all the (theoretical) races that
entails :-)
How does that sound?
David
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal
More information about the Hal
mailing list