Stefan Richter wrote:
All transports implement HCIL mappings. (SPI drivers enjoy the easiest mapping, hcil<->HCIL.) They are all faced with the necessity of mapping and solve it in different ways, for different reasons. Why stop at FC + SAS and try to find a unified solution for just those two? Also, when you are working out how FC and SAS could interface to a common HCIL mapping library (or HCIL mapping layer?), you are effectively designing aspects of how an interface between FC|SAS and SCSI core should look like. Or, why not provide the HCIL mapping helpers in the core and subsequently make users of this new interface completely unaware of the existence of HCIL...?
Ignoring some legacy ioctls and bits of existing code... The only mapping that's _really_ required is an internal C pointer, used by the device class to send messages to the transport class.
Adaptec's code does a bit of that on the transport side, but we'd need to update all the existing device classes (sd, sr, st, ...) before they had been converted to a purely using pointers to connect the transport to the device.
Getting to the point where device classes need only to do transport_instance->send_message(scsi command | TMF) and where the transport class replies with device_instance->send_message(scsi response | TMF response) may be a long term goal. Depends on where evolution takes us...
Moreover, HCIL mapping is but one aspect of a common problem. As an example, I think yet another aspect of the same problem is that device properties like target names and LUNs get lost below the transport<->core interface. We want to present these device properties to userspace in a unified manner. Here it becomes even more clear: Neither is it a problem for FC and SAS alone, nor are transport-level helpers a good solution to the problem.
Target names are already in the generic device. Luben has a good point, though, that there may be multiple "labels" for the same addressible object.
I freely admit that I don't have a picture of where the real difficulties lie; I am far too unfamiliar with the innards of scsi core. But time spent on transport-level helpers which are meant to ease symptoms of the transport<->core difficulties seems to be spent rather ineffectively to me. More concrete, what is the ratio of benefit to cost of HCIL mapping code sharing between SAS and FC? Especially since that mapping is deemed obsolete already (in the long term or perhaps even mid term). And to completely go back to the subject: Will attempts on code sharing between FC layer and SAS layer bring things forward in the short-term goal of SAS integration?
HCIL mapping is a simple and very small part of this task :) There are a bunch of line items to tackle, including SMP and SDI details, all bundled up in this.
Jeff - : 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
