On 10/4/05, Bartlomiej Zolnierkiewicz [off-list ref] wrote:
On 10/4/05, Jeff Garzik [off-list ref] wrote:
quoted
Brian King wrote:
quoted
The following patches enhance libata to allow SAS device drivers
to utilize libata to talk to SATA devices. It introduces some
new APIs which allow libata to be used without allocating a
virtual scsi host. This is just a snapshot of what I've
come up with at this point and I figured I would post it to
see if I was heading in a reasonable direction or not, so
don't expect the code below to do anything useful at this point
as it is untested.
hmmmm, neat. My gut feeling feeling says a slightly better direction
might be warranted, but I'll have to think a bit to put that feeling
towords.
* One thought is the desire to allocate a single ata_host_set for the
HBA, rather than avoiding ata_host_set.
For SAS we should definitely avoid ata_host_set.
quoted
* Another thought is the locking scheme -- Christoph once poked me about
libata's use of scsi_assign_lock(), which I rather like but he didn't :)
So by the transitive(?) property, if libata's locking is useful, then
your solution is probably OK. And vice versa.
host_set->lock is not useful for SAS et all and libata can
be easily fixed to not require it for SAS (I'll make a patch later).
Attached (sorry for that but I needed to push it through gmail).
Please note that all other usages of host_set->lock are dependent on
existence of hardware (S)ATA port which is simply not a case for SAS.
We can also avoid using host_set entirely by allowing SAS layer to only
register struct ata_port.
Thanks,
Bartlomiej