Subject: Re: status of the thorpej_scsipi code
To: Jon Lindgren <email@example.com>
From: Jason R Thorpe <firstname.lastname@example.org>
Date: 03/28/2001 12:32:42
On Wed, Mar 28, 2001 at 02:26:03PM -0500, Jon Lindgren wrote:
> This is definitely a dumb question, but can someone give me an outline of
> what this code actually does differently than -current? Is this a new
> structure of the code, or can we now use target mode on adapters, etc...
Eventually, a generic target mode should be added.
But, mostly, what the thorpej_scsipi code does it provide a bunch of
other stuff in the midlayer:
- Command queueing and resource management.
- Generalized and more flexible support of tagged queueing.
- Explicit feature activation (sync, wide, tqing, etc.).
- Clean separation of peripherals, channels, and adapters.
- Better error recovery.
...which means that the adapter drivers don't have to manage all that
I also am thinking that the thorpej_scsipi scheduler should be simplified
by removing all of the wait/poll code, and assuming that all jobs are run
asynchronously, and add explicit scsipi_xfer_wait() and scsipi_xfer_poll()
routines (the latter would call into the driver since it would be used
when interrupts are not available). If we do that, however, we'd have to
re-think how error recovery is done.
I think I'd also like to have the autoconfiguration machinery change to
work more like:
siop* at pci?
scsipi* at siop?
starg* at scsipi? target ?
sd* at starg? lun ?
st* at starg? lun ?
cd* at starg? lun ?
There are devices out there (in particular, a certain SCSI terminal server
device, yes, for real) which might look like this:
scsipi* at siop?
stermsrv* at scsipi? target ?
# The in/out directions of the various terminals on the server are provided
# by different luns on the target.
...but anyway, I think we could burn that bridge later.
-- Jason R. Thorpe <email@example.com>