On Thu, Jan 24, 2013 at 8:55 AM, Gwendal Grignou <gwendal@xxxxxxxxxx> wrote: > I see. But this behavior """numbers which are entirely independent of > driver probing order.""" is not consistent with the rest of scsi > subsystem Sure it is, in most interesting cases. > for instance scsi_host are named using a global number as > well; sas object naming is completely dependent on the probing order. Right, but the host number is not interesting at all, it obviously always depends on the order devices are probed. What's interesting is lun, target and the like, and they are still just nice and local numbers, not meaningless global counters. > The idea behind using the global number is to be able to link ata > objects to their pci object parent as they are named in dmesg, so that > we see error messages in dmesg we could locate the whole topology. Which is absolutely no reason to use global counters for things that have a well-defined meaning like a device's port number. Nothing here is limited to a single number,we have strings not numbers. :) ATA can surely do what USB, PCI, everybody else, even SCSI itself does, and append the real and meaningful numbers to the parent name, and all will be meaningful and will be unique. > The name of the object needs to contain <global port>. > If we want to add <local port> , to be consistent with sas sysfs, I > suggest <object_name><global port><separator><local port> syntax. > <separator> is ':' for scsi transport, but I used '.' already, so we > can continue with it. Sure, we need to add something that makes the name unique in the class, but we should also export the real names and not only the artificial and meaningless counters. There is a good reason SCSI repeats the "real" and meaningful numbers in the LUN 0:0:0:0 device name, and ATA should just do something like that too. :) Kay -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
