Re: [BK PATCHES] add ata scsi driver

[Linus Torvalds <torvalds@transmeta.com>]

On Mon, 26 May 2003, Jeff Garzik wrote:
> >>I think with SATA + drivers/ide, you reach a point of diminishing 
> >>returns versus amount of time spent on mid-layer coding.
> > 
> > I think that's a valid approach, and just have a special driver for SATA. 
> > That's not the part I worry about. 
> 
> You're still at a point of diminishing returns for a native driver too.

No, because for a block-queue native driver there would be one huge 
advantage: making sure the native queueing is brought up to be a fully 
used interface.

Originally, native queueing was all there was, and all drivers interfaced 
directly to it. The IDE and SCSI layers ended up being used largely
because they allowed drivers to use a global naming scheme, not because 
they were "better". In fact, in many ways they were a lot worse than the 
native queues, but then they had some other infrastructure that did help.

My bet is that most of that infrastructure today is just not worth it.

> Userland support is nonexistent, and users would have start using yet 
> another set of tools to deal with their disks, instead of the existing 
> [scsi] ones.

That's not true. The command set is already exported, so that even things 
like packet commands can be sent (that's how you write CD-RW under 2.5.x, 
and it's the _generic_ layer that does all the command queueing). 

That, btw, i show you should do the ATA transport thing. Even SCSI devices 
can get the commands fed that way. It's neither ATA nor SCSI, it's a 
"packet interface for the generic queue".

The only remaining piece of the puzzle (from a user land perspective) ends 
up being the mapping from major/minor -> queue. That used to be a _huge_
issue, and the main reason you couldn't write a SCSI driver outside the 
SCSI layer, for example (but look at DAC960 - it decided to do so 
_anyway_, even if it meant being ostracised and put on a separate major).

But that should be much less of an issue now, since our queue mapping is a 
lot more flexible these days.

> Device model, power management, hotplugging are all handled or 
> in-the-works for scsi, and they are exactly what SATA needs.

Clue-in-time: if hotplugging doesn't work on a native level, it won't work 
on a SCSI level either. So that _cannot_ be a real issue.

Device model stuff and power management all comes from other areas, and 
have little to do with SCSI.

		Linus