Luben Tuikov <luben_tuikov@xxxxxxxxxxx> wrote:
> On 10/08/05 10:30, James Bottomley wrote:
> > But it doesn't represent a SCSI domain; it represents a particular type
> > of SCSI domain (as you say yourself, SAS or SATA). I'm trying to eject
>
> That's true.
>
> > transport specific knowledge from the mid-layer, so a domain device that
> > would be used in the mid-layer should be capable of representing any
> > SCSI domain (FC/SPI/SBP etc ..). I suppose in the worst case, anything
> > that comes back to the mid-layer from the transports should be relevant
> > to at least two separate transports.
>
> struct scsi_domain_device { ... }; (to be created) is your friend.
>
> The only way that that design
> "should be capable of representing any
> SCSI domain (FC/SPI/SBP etc ..)"
>
> Is if it _does not_ have any knowlege about the underlying
> physical domain -- just as it is shown in SAM (and that is the whole point).
> Else you get in this neverending cat-and-mouse game. If you have the
> abstraction right, then whatever new transport comes along, it would
> be properly represented.
>
> > Let Jeff come up with the incorporation scheme and see how it looks.
>
> Hmm, I haven't seen or heard anything from Jeff. Have you?
>
> I have no idea what his plans are. If the idea is to create
> struct scsi_domain_device { ... }; and start from there,
> then I'd like to be involved since this was what I'd wanted
> for SCSI since 2002.
>
I would also be interested in the incorporation work. I have been running
Luben's patches on a couple of x460s. I was also reading, hacking, and
experimenting on the two sas classes to understand them better and would
like to help if I can.
-andmike
--
Michael Anderson
andmike@xxxxxxxxxx
-
: 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
