Re: [RFC] libata new EH document

Luben Tuikov
2005-09-01T23:17:24Z

On 09/01/05 18:27, Jeff Garzik wrote:
>>I think it's only because "it's there" and that it provides
>>a uniform access -- provided by SCSI, _not_ by that particular
>>SCSI implementation.
>
>
> You're correct in one sense, but I still don't think you understand
> Linux development at a fundamental level.
>
> Linux is NOT about big designs. Linus says "do what you must, and no
> more." Linux is a fluid, organic biological organism that evolves
> through small changes over time.

Jeff, this is no longer true.

Maybe in the years 1991-1995, but this is _absolutely_ no longer true.
Far more so for SCSI Core. Read Documentation/ManagingStyle.

Furthermore, take a look at the changes Christoph is about to
do now regarding, about and around struct scsi_target.

Those changes have been talked about _before_ Christoph
moved from XFS to SCSI Core and _before_ you moved from
8139too to SCSI Core, first by Justin Gibbs and then by, yours
truly.

Another expample, 64 bit LUNs. First they are not supported,
second, they are _interpreted_ by SCSI Core in scsilun_to_int().
This is beyond wrong, this is incompetence.

I've been asking for those since 2000, after my work on iSCSI.

So, as you see, _you are right_, but only for *other* Linux
subsystems, where their maintaners operate on the Documentation/ManagingStyle
style. Here at SCSI Core, the maintainers like to control everything,
and unless _they_ themselves came up with the idea, to reject it
immediately.

So over the years, a lot of "design features", "enhancements", etc
have stacked up, against the antiquated SCSI Core. It is very sad
and unfortunate.

Had those been listened to and heeded to, we'd have the human
framework that you talk about.

The best thing you can have is maintainers who _listen_ to people
and _listen_ to core engineers who _live and breathe_ the industry.
This is the Documentation/ManagingStyle.

The worst thing you can have is maintainers who try to _guess_
and do their own designs and whims, without actually addressing
real problems which exist now and have existed for a long time.

The presense of channel/id in SCSI Core. It is unthinkable to leave
that in and go and work on a "transport class", whatever that means.

Priorities need to be set straight. The architecture (future) needs
to be studied or at least the maintainers should listen to vendors
and double check with others and then triple check with a spec.

Parallel SCSI is slowly and surely going away.

FC, USB, FireWire, SATA and SAS is coming our way and will completely
replace SPI.

You can join the future or you can steadfastly hang on to something
which you know will not cut it anywhich way you mess with it.

> So, yes, the reason is "it's there" And that's a really good reason!
>
> The future will bring other "baby steps" that evolve us towards a more
> modular design where each LLD may register themselves with a storage
> system, associate themselves with one or more transport classes, which
> in turn create associations with device classes.

I have this working already _and_ it is T10 compliant.
It is modular and _layered_.

> Queueing, EH, transport classes (which should already be independent of
> SCSI), maybe driver API, and other fun stuff. :)

You'd better have one good and well thought out infrastructure...!
Of course you cannot do any of this unless a lot of specs have been
read and studied.... It's like writing papers -- you do if after having
read a lot of them.

As to your saying
"transport classes (which should already be independent of
SCSI)"
You see, this will _never_ happen.

First of all, them JB's "transport classes" were writting ONLY
to export *attributes*, and _never_ to provide a layer of abstraction
for the specific transport.

Second, as I mentioned in a previous email, you cannot create
a "superclass" of all transports. Because:
- this is what SAM is,
- this is what SCSI Core *should be*!

Third, they were never intended to *manage* a transport infrastructure.
Just look at the troubles they have with SAS's infrastructure.

Fourth, they are "hooked" at the _wrong_ level and indirection,
just as you say
"transport classes (which should already be independent of
SCSI)".
They are NOT and will never be -- the mindset of their creators
is that they will control also the transports, instead of
concentrating on SCSI Core.

So all in all, a lot of thinking needs to be done. Add to this
a white sheet of paper, pencil on one side and a spec on the other.

Luben