> -----Original Message----- > From: James Bottomley [mailto:James.Bottomley@xxxxxxxxxxxxxxxxxxxxx] > Sent: Friday, December 18, 2015 9:14 AM > To: Hannes Reinecke <hare@xxxxxxx>; KY Srinivasan <kys@xxxxxxxxxxxxx>; > gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > devel@xxxxxxxxxxxxxxxxxxxxxx; ohering@xxxxxxxx; > jbottomley@xxxxxxxxxxxxx; hch@xxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx; > apw@xxxxxxxxxxxxx; vkuznets@xxxxxxxxxx; jasowang@xxxxxxxxxx; > martin.petersen@xxxxxxxxxx > 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
