ID_PATH generated by path_id.c doesn't differentiate ide devices
Hi!
As of udev 143, the former path_id shell script has been replaced by a version written in C. The new version doesn't have any special handling for ide devices, as the old one does. As a consequence, a device formerly known as "ID_PATH=pci-0000:00:1f.1-ide-0:1" now is only called "ID_PATH=pci-0000:00:1f.1", causing persistent naming rules to become obsolete. Furthermore, multiple devices attached to the same controller can't be distinguished by their ID_PATH at all.
Was this change intentional? Was there some discussion about it, and if so, can you point me at an archived version of it? I found none.
Is the omission of the ide port going stay, or will ide handling be reimplemented eventually?
Is there some "official" suggestion as to what parameter to use for persistent device naming rules, instead of the ID_PATH? Would you suggest KERNEL as the closest replacement to ID_PATH, or rather ID_MODEL or similar, in order to name devices rather than the ports they connect to?
I first reported this issue for Gentoo as http://bugs.gentoo.org/281558
I'm not sure how much of the Gentoo persistent device naming scheme comes from the udev sources, but at least the path_id change I could identify in the current udev git sources as well.
The commit introducing the switch to the C implementation:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=185ea6a76d3f
Greetings,
Martin von Gagern
Quoted 3 lines · Martin von Gagern
As of udev 143, the former
path_idshell script has been replaced by a version written in C. The new version doesn't have any special handling for ide devices,
But the by-path links work for me (also using -143 for the moment) using the libata driver in the kernel for my IDE chipset. I *think* this was mentioned as the reason in the release announcement, or maybe just in the git commit message? I saw it somewhere.
Is there a reason your kernel doesn't have libata turned on? (Chipset doesn't work yet perhaps?)
In general, the udev maintainers seem to be riding the bleeding edge of everything else pretty closely; I'm surprised that a version of path_id that worked with non-libata had stayed around as long as it did...
Quoted 2 lines
Is the omission of the ide port going stay, or will ide handling be reimplemented eventually?
I *think* there were comments somewhere to the effect of "let's see how many people actually need this". Or maybe it was "if you need this, you'll have to add it yourself"? Can't remember for sure.
Quoted 9 lines · Bryan Kadzban
Quoted 3 lines · Martin von Gagern
As of udev 143, the former
path_idshell script has been replaced by a version written in C. The new version doesn't have any special handling for ide devices,But the by-path links work for me (also using -143 for the moment) using the libata driver in the kernel for my IDE chipset. I *think* this was mentioned as the reason in the release announcement, or maybe just in the git commit message? I saw it somewhere.
I guess I found it:
commit 33a76159433a5763ff6050cfaaee8fd897102639
Author: Kay Sievers <[email protected]> Date: Mon Jun 8 16:51:13 2009 +0200
path_id: delete old shell script
Removed with this is SAS disk support which never really worked properly, and legacy IDE disk support, which can be re-implemented if needed.
Quoted 2 lines
Is there a reason your kernel doesn't have libata turned on? (Chipset doesn't work yet perhaps?)
Historical reason is http://bugzilla.kernel.org/show_bug.cgi?id=7507 . Current reason: don't try to fix it if it ain't broken. :-) In fact I hadn't even remembered that I had blacklisted the pata_it821x module on my system. libata is enabled, just not used for pata.
Quoted 3 lines
In general, the udev maintainers seem to be riding the bleeding edge of everything else pretty closely; I'm surprised that a version of
path_idthat worked with non-libata had stayed around as long as it did...
Well, I guess the script was simple and stable enough that it wasn't affected by any of the bleeding-edge modifications until it got rewritten.
Quoted 6 lines
Quoted 2 lines
Is the omission of the ide port going stay, or will ide handling be reimplemented eventually?
I *think* there were comments somewhere to the effect of "let's see how many people actually need this". Or maybe it was "if you need this, you'll have to add it yourself"? Can't remember for sure.
OK, I would have been needing it, but on the other hand, by now I've rewritten my own rules, so you don't have to fix it just for me. I don't know if me encountering this issue is a good indication that others might need it fixed.
On the whole, I'm not happy with deliberately breaking working behaviour, in particular given the fact that there are a really HUGE number of different kernel and system configurations out there, so any assumption about how a system is configured is probably wrong in a number of cases.
On the other hand I can understand it if you don't want to implement features nobody is going to need. I don't know how much work re-adding these features would take, how close to the ata case they are. I would imagine it should be fairly easy, and would like to see it done, but I don't need it myself, and won't have time to write a patch.
At the very least, take a mental note that there is one case where it would have been needed, so you can count multiple occurrences until some kind of threshold is met. :-)
Greetings,
Martin von Gagern