RE: [PATCH] - Fusion-MPT much faster as module

[Moore, Eric Dean]

On Tuesday, March 22, 2005 12:05 PM, James Bottomley wrote:
> On Tue, 2005-03-22 at 11:40 -0700, Moore, Eric Dean wrote:
> > History on this:
> > Between the 3.01.16 and 3.01.18, we introduced new method
> > to passing command line options to the driver.  Some of the
> > command line options are used for fine tuning dv(domain
> > validation) in the driver.  By accident, these command line 
> options were
> > wrapped around #ifdef MODULE in the 3.01.18 version of the driver.
> > What this meant is when the driver is compiled built-in the kernel,
> > the optimal settings for dv were ignored, thus poor performance.  
> 
> OK, I'll add this to the queue.
> 
> Could I just point out that if your driver actually printed 
> the results
> of negotiation, this would have been an awful lot easier to debug.
> 
> Additionally, if you used the SPI transport class domain 
> validation, the
> issue wouldn't have arisen in the first place.
> 
> James
> 

Yes, I agree with you.

I'm actively working in the background to split the mptscish driver into
separate bus type drivers.  One for fiber channel, one for SCSI, and
one for eventually SAS.  This was a request from you long time back, at
a time when I tried to submitting a patch having FC transport attributes
support.
I think once I submit that, then we can start taking a looking at supporting
the SPI transport layer.  

I still wonder if the SPI transport layer will work for RAID volumes.  
Do you know if the spi transport layer supports dv on hidden devices in a
raid volume? 
Meaning these hidden physical disks will not been seen by the block layer,
however 
spi transport layer would be aware so dv can be performed those hidden disk?

Eric 






-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/