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

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 ?

etc.

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 <thorpej@zembu.com>