udev enhancements
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
Signature · 15 lines
Dr. Hannes Reinecke [email protected] 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Hannes Reinecke
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 usingdevice_idto fetch information about a partition, we're triggering hotplug events for each partition, which causesdevice_idto 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.
in fedora udev-048 we use in udev.rules:
KERNEL="hd[a-z]*", BUS="ide", SYSFS{removable}="1", NAME{ignore_remove}="%k"
this prevents the removal of the device nodes.
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 3 lines · Harald Hoyer
KERNEL="hd[a-z]*", BUS="ide", SYSFS{removable}="1", NAME{ignore_remove}="%k"
this prevents the removal of the device nodes.
Is there a way to remove only the symlinks and leave the device nodes? Some people are concerned about the rpm -V $foopackage output. I dont want to argue with them.
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 10 lines · Hannes Reinecke
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.
Quoted 2 lines
These information is mostly gathered from the device name. Of course, you can't do that if you're using udev.
Why? You still know the sysfs path with the kernel device name in it.
Quoted 6 lines
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 ...
Why do you want to link against it? What's the problem with executing it, which is much easier to maintain?
Quoted 12 lines
- 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 adevice->partitionrelationship, we could re-use the information from the device and just paste the partition-specific bits to the end.
You may just use a PROGRAM script on the partitions rule, that returns the node name of the main block device.
Kay
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 12 lines · Hannes Reinecke
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.
Quoted 8 lines
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 ...
Look at how HAL uses udevinfo to get this kind of information. You don't need to make udevinfo into a library to do this. In fact, now that the udev database is just a directory of files, you don't really need udevinfo to get this yourself (just be careful if we change the database format in the future...)
Quoted 2 lines
- Add a 'dry-run' logic to udev/udevinfo: Given a devicename, how would a partition on that device be named?
Look at udevtest, that provides a "dry-run" functionality.
Quoted 5 lines
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 usingdevice_idto fetch information about a partition, we're triggering hotplug events for each partition, which causesdevice_idto re-run, which causes hotplug-events, which ...
Use {all_partitions} for such devices. Linus has even argued that udev itself should do this by default for these types of things just to make it simpler.
thanks,
greg k-h
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel