Re: [PATCH] minimal SAS transport class

[Luben Tuikov <luben_tuikov@adaptec.com>]

On 08/18/05 13:56, Christoph Hellwig wrote:
> I was trying to avoid the need for an rport object, but I'm not yet sure
> it's feasible.  We certainly won't put in target-persistency support
> similar to FC, that was just a hack to get the existing drivers migrated
> without lots of complaints, it's not going in for new transports like
> SAS or iSCSI.

Hmm, I remember working on iSCSI exactly 5 years ago.
Is this considered new?  (er, I mean in light of SCSI Core)

I also remember it was that time when I asked about 8 byte LUNs
to be supported transparently by SCSI Core.

It was also that time when I asked for "target" to be supported
without "channel" and "id" as this had to be invented by
the iSCSI LLDD as it needs to be invented by FC and USB.

It was also that time when I asked for "target" to be
represented transparently so that SCSI Core can do LU
discovery and register the devices found and register
them with the Command Set Drivers (sd, st, etc).

On all three points I saw great opposition from the maintainers.

Sadly, I had implemented all those things, but the products
(target and initiator) was closed source.

This is where scsi_done_q and scsi commands from slab cache came from...

>  What we might need an rport for is to support SMP.  I'm
> not yet sure how to do SMP passthrough, but we will need some object
> to represent SMP ports.

Why?  How is this going to be used?  What is the architecture model?

	Luben