From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hannes Reinecke Date: Thu, 16 Dec 2004 09:27:59 +0000 Subject: udev enhancements Message-Id: <41C1551F.6060601@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org Hi all, I'm trying to figure out the best way to incorporating udev into some=20 system tools. Currently we're facing the following problem: Any program dealing with device nodes (e.g. parted) need to figure out=20 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,=20 you can't do that if you're using udev. So, to retain the existing functionality we would need to add two major=20 improvements to udev: - Build udevinfo as library. This way any program can just link to this=20 library and retrieve any information from there instead of rely on some=20 build-in logic. That should actually be quite simple ... - Add a 'dry-run' logic to udev/udevinfo: Given a devicename, how would=20 a partition on that device be named? The latter is the _really_ hard part. Currently there is no relationship=20 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=20 run-time behaviour of udev significantly. With the current setup we have to re-run any program fetching=20 information about the device (e.g. scsi_id) every time a new partition=20 has been detected. If we had a device->partition relationship, we could=20 re-use the information from the device and just paste the=20 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,=20 we're triggering hotplug events for each partition, which causes=20 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=20 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 --=20 Dr. Hannes Reinecke hare@suse.de SuSE Linux AG S390 & zSeries Maxfeldstra=DFe 5 +49 911 74053 688 90409 N=FCrnberg 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.=20 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