Re: [RFC] libata new EH document

[Jeff Garzik <jgarzik@pobox.com>]

Luben Tuikov wrote:
> On 09/01/05 17:46, Jeff Garzik wrote:
> 
>>>>>libata is simply being lazy:  while the SCSI core continues to support
>>>>>kicking the EH thread when sense is missing, it's preferred for libata
>>>>>to reuse that infrastructure.
>>>>
>>>>
>>>>That makes the most sense ;-)
>>>
>>>
>>>For libata it doesn't really matter, since it is _ATA_.
>>
>>It matters quite a bit.  One of the main reasons libata uses the SCSI 
>>layer is for its infrastructure.
> 
> 
> Hmm, maybe I should've been more clear.
> 
> 
>>This is the same reason a couple RAID drivers use the SCSI layer.  It 
>>has nothing to do with SCSI-as-defined-by-T10, and more to do with the 
>>fact that SCSI provides a robust queueing/EH/block interface infrastructure.
> 
> 
> You must be kidding! "robust"?  What are you comparing this to?
> 
> 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.

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.


>>My long term plans include moving some of this not-SCSI-related 
>>infrastructure from the SCSI layer to the block layer.
> 
> 
> Which is that infrastructure?

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

	Jeff