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

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

[Martin von Gagern]

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

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

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

[Bryan Kadzban]

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

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.

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...

> 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[Martin von Gagern]

[-- 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 --]