[lvm-team] Soliciting feature requests for development of an LVM library / API

[Alasdair G Kergon]

On Mon, Dec 15, 2008 at 03:00:41PM -0500, David Zeuthen wrote:
> I'm not sure we want to extend the udev database; in my view it's
> supposed to be a small and efficient mechanism that allows one to
> annotate directories in /sys with additional information that we collect
> in user space.
 
So we need another database to 'wrap' around the udev one.

Could the udev database at least store 'claiming subsystem' information?
e.g. that device X is 'claimed' by LVM2; device 'Y' is 'claimed' by md etc.

> FWIW, in many ways, one can think of the udev database as an extension
> of sysfs insofar that attributes in sysfs represents information / state
> exported by the kernel driver while attributes in the udev database
> represents information / state exported by a user space programs /
> daemons.

Just state, not new classes of entities that have no correspondance with
sysfs (such as 'Volume Groups')?
 
>  3. Finally we can discuss how this information can be used to implement
>     policy by writing very simple udev rules that leverages the info in
>     the udev database defined in 1.
>     For example, one thing many people (desktop developers like me
>     but also people working on initramfs/booting (jeremy, davej)
>     and also anaconda) probably want to request is that device-mapper
>     and LVM ship with udev rules that uses the information defined in 1.
>     above to implement a policy that automatically assembles LV's from
>     PV's. If we solve 1. correctly, this *shouldn't* be more complicated
>     than a simple one-liner udev rule.

Those rules - triggers - depend on these additional entities (Volume Groups).

The way we store and index and trigger using this Volume Group information is
critical to this whole exercise and has to be resolved before we can really
make much more progress IMHO.

Alasdair
-- 
agk at redhat.com