udev enhancements

[Hannes Reinecke <hare@suse.de>]

Hi all,

I'm trying to figure out the best way to incorporating udev into some 
system tools. Currently we're facing the following problem:

Any program dealing with device nodes (e.g. parted) need to figure out 
some information about the device it handles:
- partition naming: given a device name, generate the name of a
   partition on that device.
- number of partitions: each block device type has it's own maximal
   number of partitions.

These information is mostly gathered from the device name. Of course, 
you can't do that if you're using udev.
So, to retain the existing functionality we would need to add two major 
improvements to udev:

- Build udevinfo as library. This way any program can just link to this 
library and retrieve any information from there instead of rely on some 
build-in logic. That should actually be quite simple ...
- Add a 'dry-run' logic to udev/udevinfo: Given a devicename, how would 
a partition on that device be named?

The latter is the _really_ hard part. Currently there is no relationship 
in udev between a device and the partitions associated to that device.
I would love to see that, though, as it would simplify the rules and the 
run-time behaviour of udev significantly.
With the current setup we have to re-run any program fetching 
information about the device (e.g. scsi_id) every time a new partition 
has been detected. If we had a device->partition relationship, we could 
re-use the information from the device and just paste the 
partition-specific bits to the end.

And it would also break the deadlock we're having now:
Removable IDE devices _always_ do a re-read partition on _open_.
So if we're using device_id to fetch information about a partition, 
we're triggering hotplug events for each partition, which causes 
device_id to re-run, which causes hotplug-events, which ...

Not nice. And no clean way to resolve it in kernel-land, either, as most 
removable IDE devices have no clean way to detect a media change.

So, would those two ideas acceptable? Or are there better ideas?
Or (preferably) better solutions?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel