Re: [BK PATCHES] add ata scsi driver

Jeff Garzik
2003-05-27T05:54:36Z

Linus Torvalds wrote:
> On Mon, 26 May 2003, Jeff Garzik wrote:
>
>>Correct, but precisely by saying that, you're missing something.
>
>
> You're missing _my_ point.
>
>
>>The SCSI midlayer provides infrastructure I need -- which is not
>>specific to SCSI at all.
>
>
> If it isn't specific to SCSI, then it sure as hell shouldn't BE THERE!
>
> My point is that it's _wrong_ to make non-SCSI drivers use the SCSI layer,
> because that shows that something is misdesigned.
>
> And I bet there isn't all that much left that really helps.
>
> You adding more "pseudo-SCSI" crap just _makes_things_worse. It does not
> advance anything, it regresses.

As you see from Alan's message and others, it isn't pseudo-SCSI.

Besides what he mentioned, there is Serial Attached SCSI (SAS), where a
host controller can simultaneously support SAS disks and SATA disks. So
it's either an IDE driver that does SCSI, or a SCSI driver that does
IDE, or a driver that's in both IDE and SCSI subsystems, or... ? Having
fun yet? :)

> On 27 May 2003, Alan Cox wrote:
>>> I actually think thats a positive thing. It means 2.5 drivers/scsi is
>>> now very close to being the "native queueing driver" with some
>>> additional default plugins for doing scsi scanning, scsi error recovery
>>> and a few other scsi bits.
>
> Hey, that may well be the way to go, in which case the core stuff should
> be renamed and moved off somewhere else. Leaving drivers/scsi with just
> the actual low-level SCSI drivers.

For all these reasons, I continue to maintain that starting out as a
SCSI driver, and then evolving, is the best route. The non-SCSI parts
leave drivers/scsi, as they should. The SCSI parts stay. The SCSI
mid-layer gets smaller. All the while, the driver continues to work.
Everybody wins.

Starting out as a native block driver and _then_ adding SCSI support and
native queueing and jazz does not sound even remotely like a good path
to follow.

Jeff