From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin von Gagern Date: Sat, 15 Aug 2009 17:47:02 +0000 Subject: Re: ID_PATH generated by path_id.c doesn't differentiate ide devices Message-Id: <4A86F496.4030706@gmx.net> MIME-Version: 1 Content-Type: multipart/mixed; boundary="------------enig9EC3A9ECFF21631B6AD50737" List-Id: References: <4A86C1BB.6020002@gmx.net> In-Reply-To: <4A86C1BB.6020002@gmx.net> To: linux-hotplug@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9EC3A9ECFF21631B6AD50737 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, >=20 > But the by-path links work for me (also using -143 for the moment) usin= g > 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 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=3D7507 . 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= =2E >> Is the omission of the ide port going stay, or will ide handling be=20 >> reimplemented eventually? >=20 > 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 --------------enig9EC3A9ECFF21631B6AD50737 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqG9JoACgkQRhp6o4m9dFvmdACfZvtnShiKpcL8R/Gpkc2oL6eL QLMAn3ZlLr0yer6x/Bl5ha5iPwza5WAY =3raA -----END PGP SIGNATURE----- --------------enig9EC3A9ECFF21631B6AD50737--