On Tue, Apr 3, 2012 at 22:25, Hannes Reinecke <hare@xxxxxxx> wrote: > On 04/03/2012 08:24 PM, Kay Sievers wrote: >> On Tue, Apr 3, 2012 at 10:04, Nils Carlson <nils.carlson@xxxxxxxxxxxx> wrote: >> >>> This patch reintroduces enumeration >>> of the form >>> >>> pci-0000:05:00.0-sas-phy0-0x500000e114de2b42:0-lun0 >>> >>> where phy0 is the reintroduced substring where 0 corresponds >>> to the lowest phy identifier on the port to which the device >>> is connected. >> >> Without having any real insight knowledge, a quick check: >> >> We usually refuse any "find the lowest number approach" in new code, >> and require the kernel to export a stable instance number per parent >> device, which is entirely disconnected from any global device >> enumeration counter or prober ordering. >> >> Almost all existing examples doing that are broken, and some even >> needed to be removed because they just blindly bet on luck that things >> are always in the same probe order. >> >> Many device can individually unbound and rebound in the kernel, so >> after the rebind the same device will no longer have a smaller number >> like it had before. Kernel enumeration is only in a very few cases >> useful to build persistent paths. >> >> The approach in this case is safe against individual pieces being >> unregistered and registered again? >> > Note, this is just a first step towards real configuration. > > This is the SAS PHY issue we've talked about earlier; eventually we'll > have to export paths for all phys. > > I'm working on a patch (on top of this one), but it'll be quite a change > to path_id. So I've asked for this patch to be sent now, rather than > wait for the full blown solution. Yeah, sure, I just need to make sure we do not do things like this any more: http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=src/udev-builtin-path_id.c;h=a8559d2dd4118ac89feb03b7db8ef364caa73a0b;hb=HEAD#l255 It is just broken, and the kernel needs to export that if we really want to use it in userspace. The kernel device name has zero meaning and we must not derive any order from it, never. Re-registering the same device will probably just break that too-simple logic. I just asked, because the requirement for new stuff is much higher today, we do not fiddle around with broken kernel interfaces anymore. If the stuff does not export the proper things, we just don't support it. The time to fiddle with symptoms is over. We either get it fixed for real, or it will just not show up in new things in higher levels in userspace, including new symlinks udev creates. And the transport classes in sysfs are just a nightmare; but I know, I don't need to tell you. :) Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
