From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965050AbbLRRNp (ORCPT ); Fri, 18 Dec 2015 12:13:45 -0500 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:49412 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932287AbbLRRNo (ORCPT ); Fri, 18 Dec 2015 12:13:44 -0500 Message-ID: <1450458820.2439.12.camel@HansenPartnership.com> Subject: Re: [PATCH V3 2/4] scsi: storvsc: Properly support Fibre Channel devices From: James Bottomley To: Hannes Reinecke , "K. Y. Srinivasan" , gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org, ohering@suse.com, jbottomley@parallels.com, hch@infradead.org, linux-scsi@vger.kernel.org, apw@canonical.com, vkuznets@redhat.com, jasowang@redhat.com, martin.petersen@oracle.com Date: Fri, 18 Dec 2015 09:13:40 -0800 In-Reply-To: <5673C893.6020204@suse.de> References: <1450038486-19211-1-git-send-email-kys@microsoft.com> <1450038512-19252-1-git-send-email-kys@microsoft.com> <1450038512-19252-2-git-send-email-kys@microsoft.com> <5673C893.6020204@suse.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. James