Bryan Kadzban wrote: > Martin von Gagern wrote: >> 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, > > 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 <kay.sievers@xxxxxxxx> 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. > 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. > 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... 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. >> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
