RE: [patch 6/8] mptfusion: fc transport

[James Bottomley <James.Bottomley@SteelEye.com>]

On Mon, 2004-12-06 at 17:29 -0700, Moore, Eric Dean wrote:
> Monday, December 06, 2004 10:21 AM, James Bottomley wrote:
> > On Mon, 2004-12-06 at 11:12, Moore, Eric Dean wrote:
> > > Our concern is the impact to linux distributions installers and
> > > end users that upgrade to these newer drivers.  
> > > Example: Someone having older driver using boot device attached
> > > to our controller.  Then they download a newer kernel from 
> > Kernel.org with
> > > newer
> > > drivers having mptfc.  They mkinitrd, or mk_initrd (without modifing
> > > linuxrc),
> > > reboot then what?  Can they see the boot partition?   
> > 
> > That's a concern only for people who boot from your fibre 
> > adapters.  How
> > many such users are there?
> 
> I'm checking into this, and let you know. I'm pretty certain
> that there are people who have blade severs connected to a SAN using
> our LSI FC controller, and then booting to devices in FC RAID storage 
> array(from other vendors) populated out on the SAN.

Well, I talked to the people in charge of the Vendor Kernel's at Red Hat
and SuSE.  They have agreed make the installer changes needed to help
people upgrading from the current monolithic fusion driver to a more
modular one.  (Sorry for the delay, it took a while to get everyone's
buy in for this).

> Also, I forgot to mention other concerns in previous email.
> 
> (1) If mptfc depends on mptscsih, then what is going to be said
> when we implement the domain validation using the spi transport layer?
> When someone loads mptfc.ko, then we need mptscsih.ko and
> scsi_transport_spi.ko
> loaded, even though there is no U320 adapter present.  The same complaint
> can
> be said here.  In my current kernel, scsi_transport_spi.ko = 35KB,
> scsi_transport_fc.ko = 27KB.

Actually, I think I'd like this to be a clean modularisation, so the SPI
functions go in one piece, the FC functions in another and the SAS
functions in yet a third.  Then everything could depend on the core
fusion engine for the interface with firmware.  That would allow:

- the transport classes to attach correctly,
- the transport dependent functions (which currently litter the driver
as if (spi) else if(fc) to be contained individually
- and the PCI ID's which will drive the installer and upgrade processes
to be stored in the transport dependent pieces.

> (2) Also, I think there is more involved than just 
> moving mptbase_pci_table from mptbase.c to mptscsih.c.
> mptbase_probe is enumerating the bus's when pci_module_init(_)
>  is called.  Would mptscsih.c be calling pci_module_init instead?  
> If so, will the current code for mptbase_probe still 
> work as is, or will it need moving to mptscsih?  If its moved, 
> then mptlan.ko and mptctl.ko would not be able to work as it does today?  
> They currently depend only on mptbase.ko.

Well, I think the true way it should happen is to make mptbase house
only the functions necessary to implement the fusion firmware API
(although generic functions could be part of it as well).  Then a true
fusion driver would have an mpt transport module, the base module and
optionally the mptlan module.  If I read mptctl right, it only
implements the RAID ioctl features, so it could likewise be optional.

James