Re: I request inclusion of SAS Transport Layer and AIC-94xx intothe kernel

[Luben Tuikov]

On 10/03/05 12:48, Jeff Garzik wrote:
> No, transport class is its name.  Think about a standard object-oriented 

Not according to Kconfig:

menu "SCSI Transport Attributes"
	depends on SCSI

config SCSI_SPI_ATTRS
	tristate "Parallel SCSI (SPI) Transport Attributes"
	depends on SCSI
	help
	  If you wish to export transport-specific information about
	  each attached SCSI device to sysfs, say Y.  Otherwise, say N.

config SCSI_FC_ATTRS
	tristate "FiberChannel Transport Attributes"
	depends on SCSI
	help
	  If you wish to export transport-specific information about
	  each attached FiberChannel device to sysfs, say Y.
	  Otherwise, say N.

config SCSI_ISCSI_ATTRS
	tristate "iSCSI Transport Attributes"
	depends on SCSI
	help
	  If you wish to export transport-specific information about
	  each attached iSCSI device to sysfs, say Y.
	  Otherwise, say N.

config SCSI_SAS_ATTRS
	tristate "SAS Transport Attributes"
	depends on SCSI
	help
	  If you wish to export transport-specific information about
	  each attached SAS device to sysfs, say Y.

endmenu

> paradigm.  Each transport has unique characteristics.  The proper place 
> to export these and manage these characteristics is the transport layer, 
> as SAM agrees.

But:

>  The manifestation of the transport layer is the 
> transport class.

Bzzzt!  Wrong.

This is where you and James Bottomley make the wrong assesment.

Having the SCSI host template in the LLDD tells everyone immeditealy
that you have it all wrong as far as anything SAM/SPC is concerned.

Look at any transport spec, how little SCSI Host template is there.

You need to understand that declaring the host template in the
LLDD is, and has always been, the _exception_, not the rule.
The reason is legacy Parallel SCSI.

It is MPT based drivers who are the exception, not the rule,
and JB's "transport attributes" makes it the rule, and a
transport layer (what you call libsas), the exception.

It is wrong for a host template to "branch out" to a
transport layer as you're doing it now.  Think about it.
The layering infrastructure is upside down.

> You have to look beyond the current code, to see this.

Eh, well, not that you put it like this, I expect that
you'll completely pull out the implementation from my code
and put it in the "transport attributes" and call it your own.

I don't want to look beyond the current code, I'm discussing
things now, as they are.  How many times is JB going to change
the "transport attributes" just because FC needed one more thing
or because of, as often has been recently seen, "brown paper bag"
fix?

> An implementation of a transport class, in conjunction with helper 
> functions common to all transports (SCSI core), combines to form the 
> transport layer for a specific transport.

Should:

The transport layer sits below SCSI Core and above the LLDD.
SCSI Core is completely unaware of the transport layer.
The LLDD communicates with the transport layer via
the event interface (as shown in the SAS Transport layer)
and the transport layer communicates with the LLDD via
the Execute Command SCSI RPC and TMF.  All as outlined here:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112629423714248&w=2

>>b) It sits across SCSI Core, i.e. on the same level.
>>c) It was never intended to add management.
> 
> 
> SCSI core is nothing but a set of helper functions and support code that 
> enable the transport class and LLDD to implement the transport layer.

Again you fail to see that the LLDD should _not_ implement
the host template as has been traditionally done.
The reason with this is that simply the LLDD has nothing to do
with the host template.  Unless you're dealing with MPT-based
LLDD which implement everything in FW and export LUs to
SCSI Core (which is fine too, as long as they do not dictate
how SCSI Core should work).

Notice that for MPT-based solution, SCSI Core wouldn't even
do LU discovery (unless you can turn that off via FW dependent
ways).

>>d) Its inteface to SCSI Core is badly defined and an "invention",
>>   (and very poor at that).
> 
> Strongly disagree.  This invention is defined by -needs-, as is other 
> code in Linux.  If we have new needs, we change the code.

You defence of your friends architecture is duly noted.
But if, as has been pointed out, you take a look at the
evolvement of this "invention" you'll see how it was and still
is _meandering_ in the technological maze to find its place.

All the while a transport layer like USB/SPB/SAS and maybe
iSCSI just sits "right".  Think about it.

>>The reason for d) is that
>>2) does _not_ follow _any_ spec or standard.
> 
> 
> That's fine, since its an internal kernel API.

Now, lets shove it down the throat of eveybody.

You forgot to say something about
1) it tries to unify different _transports_.
I don't expect a blurb on that, btw.


	Luben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/