On Monday, September 25, 2006 3:59 AM, Martin Wilck wrote: > > Ascending ID ordering does not address all cases. > > There is no guarantee which target ids are > > assigned by firmware to volumes when > > volumes are created. > > That's what my patch was supposed to handle: No matter what > the ordering > of IDs by firmware is, the devices are registered in > ascending ID order. You patch will call scsi_add_device, from low to hi target ids, right? Well if someone creates a volume that is issued target id=8, installs the operating system. Then tommorrow they create a new volume that is issued target id=7, then what your patch will do is reverse the order, right? If so, a panic would occur unless they assigned device names/lables. > > > I've made similar > > ordering proposals before to this mailing list. > > All been rejected. > > Do you have a thread reference for me? I'd like to understand the > arguments better. I find this strange because scanning in ascending > order has always been the common case in drivers as well as > in the mid > layer, AFAIK. I was working with Christoph Hellwig and James Bottomley last year implementing raid support in mptsas, and they rejected it code that ordered raid ids. BTW, the scsi mid layer is not scanning devices that use transport layers, beside spi. Meaning that lld's that are fibre channel, iscsi, and sas hba will report the know devices to transports, and the transport assign its own unique mapping. For example, mptsas and mptfc are using transport, and we don't call scsi_scan_host. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
