SCSI in a post 2.6.0 world

SCSI in a post 2.6.0 world

[James Bottomley]

With the announcement of 2.6.0, I've dusted off the scsi-misc-2.7 tree
at

bk://linux-scsi.bkbits.net/scsi-misc-2.7

I'm afraid, until the new merge criteria are announced, you can't assume
it will contain the actual changesets that will be merged (I may need to
take it apart and redo it),  but it's a good start for people who want
to begin ongoing SCSI development again.

James

Re: SCSI in a post 2.6.0 world

[Jeff Garzik]

On Thu, Dec 18, 2003 at 09:48:05AM -0500, James Bottomley wrote:
> With the announcement of 2.6.0, I've dusted off the scsi-misc-2.7 tree
> at
> 
> bk://linux-scsi.bkbits.net/scsi-misc-2.7
> 
> I'm afraid, until the new merge criteria are announced, you can't assume
> it will contain the actual changesets that will be merged (I may need to
> take it apart and redo it),  but it's a good start for people who want
> to begin ongoing SCSI development again.

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.
(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.

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.

FWIW.

	Jeff

Re: SCSI in a post 2.6.0 world

[James Bottomley]

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

Re: SCSI in a post 2.6.0 world

[Jeff Garzik]

On Thu, Dec 18, 2003 at 10:40:14AM -0500, James Bottomley wrote:
> 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.

No need for caveats.  There will be no register-based LLD API.

Command-based is fine.  SATA _needs_ command-based, because ATA these
days is queued.

Recall, some crazy cracker created ATA-over-ethernet <grin>


> > (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).

You got it.


> > 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.

Indeed.


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

Absolutely.  /dev/tape is part of this too.  And I'm hoping SCSI
generic will go away in favor of Jens' "bsg", which allows userspace
to send SCSI CDBs, ATA taskfiles, RAID I2O messages, or whatever.

	Jeff

Re: SCSI in a post 2.6.0 world

[Andre Hedrick]

JG,

I gotta stop having these midnight sessions of conversation with you, one
idea and you explode in a fever to change the world.  I agree of the need,
I just have concern for actually deployment with out a dual path for
testing.

Recall our discussion on ./drivers/storage

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Thu, 18 Dec 2003, Jeff Garzik wrote:

> On Thu, Dec 18, 2003 at 10:40:14AM -0500, James Bottomley wrote:
> > 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.
> 
> No need for caveats.  There will be no register-based LLD API.
> 
> Command-based is fine.  SATA _needs_ command-based, because ATA these
> days is queued.
> 
> Recall, some crazy cracker created ATA-over-ethernet <grin>
> 
> 
> > > (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).
> 
> You got it.
> 
> 
> > > 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.
> 
> Indeed.
> 
> 
> > As part of this project, were you planning to look at how character
> > devices can be improved?
> 
> Absolutely.  /dev/tape is part of this too.  And I'm hoping SCSI
> generic will go away in favor of Jens' "bsg", which allows userspace
> to send SCSI CDBs, ATA taskfiles, RAID I2O messages, or whatever.
> 
> 	Jeff
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: SCSI in a post 2.6.0 world

[Jeff Garzik]

Andre Hedrick wrote:
> idea and you explode in a fever to change the world.  I agree of the need,
> I just have concern for actually deployment with out a dual path for
> testing.


Not change the world, just update it a bit :)

I fully intend to leverage existing -tested- SCSI code.

	Jeff