Re: Merge I2O patches from -mm

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Maw, 2004-08-17 at 14:31, Markus Lidel wrote:
> > Now to i2o_scsi:
> >  - the logic of "demand-allocating" Scsi_Hosts looks rather bad to me,
> >    life would be much simpler with a Scsi_Host per i2o device.
> 
> But wouldn't it be a waste of resources to allocate a Scsi_Host 
> structure for every I2O device? Note that the i2o_scsi "sees" all disks 
> even if they are in a RAID array, so in most cases there are at least 3 
> Scsi_Host adapters...

Christoph the "I2O" device is a communication processor. You need to
preserve the real scsi busses in order to get sane results from scsi
tools. If EH is implemented you'll need this to do controlled resets
(although this gets quite umm 'interesting' if using i2o_block also)

You've got

	I2O comms processor
		Multiple scsi busses
			Multiple drives
		Block driver providing abstract volumes

Sometimes (as with other raid) bypassing the block driver is faster.

> >  - the completely lack of SCSI EH in this driver scares me, does the firmware
> >    really handle all EH?
> 
> The i2o_scsi driver is not used to access the disks, it is only for 
> monitoring. The i2o_block driver handles disk access. So if you reset 

(not always - the FC920 is way faster using i2o_scsi for the disk I/O)

> the SCSI channel in the i2o_scsi driver, commands which are transfered 
> by the i2o_block driver will be aborted (this is the reason, why the I2O 
> subsystem didn't work for users, which compiled in i2o_scsi and 
> i2o_block into the kernel)...

All error timeout handling is done by the controller. It does really
need minimal EH handlers simply to reissue failed timed out commands.