First try at improving hal's device mapper support

[Sjoerd Simons]

On Fri, Dec 31, 2004 at 03:15:46PM +0100, David Zeuthen wrote:
> On Wed, 2004-12-22 at 21:22 +0100, Sjoerd Simons wrote:
> 
> 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.

I would like things to be represented in hal the right way without forcing the 
user to use certain tools/naming convetions. In my view everything in hal
should just work without relying on userspace conventions.

I don't understand what you mean with fake parents, but it sounds wrong :) 
  
> 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. 

That was the next thing i wanted to publish in sysfs. The kernel does store it
currently, but not associated with the mapping object itself. For both methods
(syfs entry or ioctl) it needs to be reachable from the mapper object itself.
  
> 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 :-)

If sysfs had the name of the mapping, there wouldn't be a need for an ioctl by
udev.. It would just work with a simple udev rule ;)
  
> 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 :-)

Maybe, depends on how open the device mapper people are to suggestions :)

I think publishing more information in sysfs about the device mapper is usefull
anyway.. That it makes things easier for hal is just a nice coincidence :)

In the end both methods have the problem that we currently can't represent a
device with multiple parents in hal. Any ideas about that ?

  Sjoerd
-- 
Prototype designs always work.
		-- Don Vonada
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal