Re: SCSI in a post 2.6.0 world

[James Bottomley <James.Bottomley@steeleye.com>]

On Thu, 2003-12-18 at 10:31, Jeff Garzik wrote:
> FWIW, I'm going to be working in this area, for 2.7.
> 
> My plan has two main goals,
> 
> (a) move the low-level driver API "up" from SCSI, to be available to all
> block drivers.

I agree with this, with caveats: the LLD API for SCSI is designed to be
a command based API, not a register based one.  I see no reason not to
have either a second LLD API that is register based, or a command to
register converter API (sort of like how ide-scsi should have been
done), but I think more discussion on how to do this needs to take
place.

> (b) consolidate "personality" code:  foodisk.c will drive
> PATA/SATA/SCSI/RAID/whatever disks.  foocdrom.c will drive cd-roms.
> footape.c will drive tapes.

In principle this is fine...both SCSI and IDE today use request prep
functions.  It's not such a huge step to do the personality processing
in the prep function (a bit like ide-cd does).

> The overall goal is to have all low-level block drivers at the same
> level, simply utilizing subsystem-specific hooks to provide
> SCSI-specific behavior.
> 
> And all this will be accomplished through evolution of existing code.
> You have convinced me that SCSI doesn't need yet another rewrite ;-) so
> I will be leveraging all the work that's gone into SCSI in 2.6...
> 
> Whenever you hear me mention "/dev/disk", the above is what I am
> referring to.

Well, I'm agnostic on that one.  Having major number discrimination
among ULDs does help figure out command routings, but if it can be done
another way...At the end of the day, udev will completely separate
numbering from naming, so /dev/disc<n> is feasible even in the current
scheme.

As part of this project, were you planning to look at how character
devices can be improved?

James