Re: [BK PATCHES] add ata scsi driver

[Jeff Garzik <jgarzik@pobox.com>]

Linus Torvalds wrote:
> On Mon, 26 May 2003, Jeff Garzik wrote:
> 
>>Direction:  SATA is much more suited to SCSI, because otherwise you wind 
>>up re-creating all the queueing and error handling mess that SCSI 
>>already does for you. 
> 
> 
> Last I looked, the SCSI interfaces were much nastier than the native 
> queueing, and if there is anything missing I'd rather put it at that 
> layer, instead of making everything use the SCSI layer.


The SCSI mid-layer has quite flexible command submission and 
synchronization.  Since each SATA host controller I've seen so far 
differs in its queueing implementation and limits, this fits perfectly 
with the existing SCSI set up.

So, short-term, I save a ton of code over a SATA block driver. 
Long-term, the SCSI mid-layer benefits from the developer attention and 
becomes more lightweight as we push some generic concepts upwards into 
the block layer.  Just look at how far scsi mid-layer has come in 2.5, 
versus 2.4!  Much more lightweight even now.

So, short-term I disagree.  Long-term, I actually agree w/ you, in an 
indirect sorta way :)


> Because when you talk about error handling messes, you're talking SCSI. 
> THAT is messy. At least judging by the fact that a lot of SCSI drivers 
> don't seem to get it right.

This isn't an issue for me.  I have to do my own error handling, in 
fact.  I just define ->eh_strategy_handler, and do my own thing.  SCSI 
mid-layer nicely provides a kernel thread and command synchronization 
before and after it calls ->eh_strategy_handler.


> In other words: I'd really like to see what you can do with a _native_
> request queue driver, and what the probloems are. And maybe port _those_ 
> parts of SCSI to it.

I considered a native block driver, or perhaps a native block driver for 
SATA and SCSI pass-thru for SATAPI.

Actually getting down to coding, I see it as a huge amount of work for 
little gain.  You have to consider all the userspace interfaces, sysfs 
and device model support that wants coding, -after- you're done with the 
basic SATA block driver.  Userland proggies already exist for scsi.

(more on this in next reply)


>>And for specifically Intel SATA, drivers/ide flat out doesn't work (even 
>>though it claims to).
> 
> 
> Well, I don't think it claimed to, until today. Still doesn't work?

Nope.  Not before or after.  (even without the patch, it should have 
worked in some amount of compat mode)

	Jeff