Re: ID_PATH generated by path_id.c doesn't differentiate ide devices

[Martin von Gagern <Martin.vGagern@gmx.net>]

[-- Attachment #1: Type: text/plain, Size: 2999 bytes --]

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@vrfy.org>
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]