On Mon, Jun 25, 2007 at 02:27:01PM -0700, Luben Tuikov wrote: > Ideally SCSI Core is presented with an opaque token (void *, unsigned long (long), > etc) which represents a target port, which it uses to send SPC commands > to the target to find out how many if any LUs the target has, INQUIRY them, > and then create struct scsi_dev for each LU. > > When presented with this opaque token*, SCSI Core allocates and > initializes a struct scsi_target, whose children are LUs, later > to be discovered by SCSI Core. SCSI Core then uses that opaque token > to ask the transport protocol layer to send commands to the I_T_L > nexus (WLUN or LUN if it knows it from previous discovery attempt). > > * Note this means that there is no "active" scanning on part > of the SCSI Core. This belongs to the transport layer. > (And thus the "concept" of "async-scanning" recently introduced > to SCSI Core, becomes moot.) Not really. The async scanning code is there to ensure that scsi devices get the same name as they would if the devices were scanned one after another. We can make all this code moot if we determine that we're willing to accept a world where 'sda' may refer to any random scsi disc. I'd be quite happy to move the code that does the "active scanning" to scsi_transport_spi.c, but right now that would be quite a bit of extra code for drivers which haven't been converted to use scsi_transport_spi yet. My nefarious plan is to convert drivers to use it, then move that code there. I do agreee with you that SPI-free systems shouldn't have to carry that legacy code around (but actually, it's very little code, so this is more of a purity thing than a real concern). - 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
