On 09/11/05 05:46, Christoph Hellwig wrote: > On Fri, Sep 09, 2005 at 07:44:54PM -0700, Luben Tuikov wrote: > >>>this one completely duplicates the >>>mid-layer infrastructure for handling devices with Logical Units. >> >>No, it does *not*. James, you have _stop_ spreading FUD, relying >>that other people have not read the SCSI Core code. >> >>See here: >> SCSI Core has *no representation* of a SCSI Device with a >>SCSI Target Port. > > > struct scsi_target > > >>I've _clearly_ outlined that in the comments of the code, >>which you _conveniently_ did _not_ cut and paste here. > > > * Discover logical units present in the SCSI device. I'd like this > * to be moved to SCSI Core, but SCSI Core has no concept of a "SCSI > * device with a SCSI Target port". A SCSI device with a SCSI Target > * port is a device which the _transport_ found, but other than that, > * the transport has little or _no_ knowledge about the device. > * Ideally, a LLDD would register a "SCSI device with a SCSI Target > * port" with SCSI Core and then SCSI Core would do LU discovery of > * that device. > > So what does this mean except "Luben tries to impress everyone with > standards gibberish, at the same time ignoring we soluitions that > work despite maybe not 100% elegant". Yes, that "maybe not 100% elegant" is what makes code survive long years, being maintainable and not spaghetti like (as new functionality is added). > Sure, we'd like to move away from needing the ->id target id specifier. > But right now we need it, even you're code sets it in over-complicated It is not "over-complicated". The functionality which is there Christoph, is there for a reason. Mainly this is experience and knowlege, but you canot _shortcut_ code, since you're eliminating an abstraction layer: one thing is done at a time at a logical layer. When all tasks are done at a logical layer, then we move onto the next. E.g. an SES device may want to do something before you transition from one stage to the next, to all devices on the same level as that SES device. (This is a topic for another thread, no intentions to mention it.) > ways. But if you send a nice patch to get rid everyone will be happy. You and I share the same passion: to improve SCSI Core. I'm not sure that a patch to get rid of id in the current SCSI Core is quite possible without major heart-attacks of quite a few LLDDs, etc. Instead, maybe, we should write a few new functions in SCSI Core which could accomodate new, improved "standards gibberish" as you call it, behaviour. Newer code would use those new functions. Older one, would use old ones. As SPI is slowly dying away, there'd be less and less need and support for the current SCSI Core, and the "new" one will emerge. Granted, in the beginning that "new" one would be one or two functions, but a start nevertheless. E.g. create a new scsi_domain_device structure and just move sas_do_lu_discovery(struct domain_device *) into SCSI Core as scsi_do_lu_discovery(struct scsi_domain_device *). Note the declaration of this new function: the decision to call it is done by the transport _layer_ since it knows whether a target port is supported or not. Then it will send a task to the scsi_domain_device, which the LLDD knows how to address. Etc. Luben - : 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
