[PATCH V3 2/4] scsi: storvsc: Properly support Fibre Channel devices

[KY Srinivasan]

> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley at HansenPartnership.com]
> Sent: Friday, December 18, 2015 9:14 AM
> To: Hannes Reinecke <hare at suse.de>; KY Srinivasan <kys at microsoft.com>;
> gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org;
> devel at linuxdriverproject.org; ohering at suse.com;
> jbottomley at parallels.com; hch at infradead.org; linux-scsi at vger.kernel.org;
> apw at canonical.com; vkuznets at redhat.com; jasowang at redhat.com;
> martin.petersen at oracle.com
> Subject: Re: [PATCH V3 2/4] scsi: storvsc: Properly support Fibre Channel
> devices
> 
> On Fri, 2015-12-18 at 09:49 +0100, Hannes Reinecke wrote:
> > What I would like to see is a clear separation here:
> > - Disable FC disk handling if FC attributes are not configured
> > - Add a module parameter allowing to disable FC attributes even if
> > they are compiled in. Remember: this is a virtualized guest, and
> > people might want so save kernel memory wherever they can. So always
> > attaching to the fc transport template will make them very unhappy.
> > Alternatively you could split out FC device handling into a separate
> > driver, but seeing the diff that's probably overkill.
> 
> I don't quite see how this can be a module parameter: the
> fc_transport_class is pulled in by symbol references.  They won't go
> away whether a module parameter is zero or one.  The only way to get
> the module not to link with a transport class is to have it not use the
> symbols at compile time (either because they're surrounded by an #ifdef
> or with an if() which the compiler evaluates at compile time to zero).
>  In userspace you get around this with introspection and dlopen, but I
> don't think we have that functionality in the kernel.

Hannes,
Perhaps I misunderstood your comment when I first responded to this suggestion
from you - I thought you were concerned about unconditionally allocating FC transport
template and I had proposed a work around that. Now looking at James comment, it looks
like you were concerned about FC transport module dependency on the storvsc module.
Do you still want me to work on my proposal.

Thanks,

K. Y
> 
> James