From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751547AbbLUQRQ (ORCPT ); Mon, 21 Dec 2015 11:17:16 -0500 Received: from mail-by2on0147.outbound.protection.outlook.com ([207.46.100.147]:8000 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751199AbbLUQRO (ORCPT ); Mon, 21 Dec 2015 11:17:14 -0500 From: KY Srinivasan To: James Bottomley , Hannes Reinecke , "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" Subject: RE: [PATCH V3 2/4] scsi: storvsc: Properly support Fibre Channel devices Thread-Topic: [PATCH V3 2/4] scsi: storvsc: Properly support Fibre Channel devices Thread-Index: AQHRNdfGoIh/UWNbT0SgmQpzhjE/ap7QdkyAgACM5QCABJ/BEA== Date: Mon, 21 Dec 2015 16:02:37 +0000 Message-ID: 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> <1450458820.2439.12.camel@HansenPartnership.com> In-Reply-To: <1450458820.2439.12.camel@HansenPartnership.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kys@microsoft.com; x-originating-ip: [2601:600:8c01:121d:2598:30fa:c26c:9617] x-microsoft-exchange-diagnostics: 1;BY2PR0301MB1653;5:BmwQT6MoSIlQRIdfhQItQ1qEJh75/4hFjCgu9lxStCEzpi4OQPOh5TU2oWAbrkpl0qUjveIPjH3lxoGloc5ynr8UlLQ5ECz+l2hSIUq4ejxJ7Kw0hHANkuZvx4omAQeX9T1UofAKDfqC8muTSUnGOw==;24:dQLU8ierqVy8TA8PE5ccCcsvQYMpugEYFkff+oS9Dm/8uHDlBXN3vM2mh/PnVD/ZZGGn8A3WFsv6I5tTK/zfQVUsGMRSi/ZLMs5uFO20/VU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB1653; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038);SRVR:BY2PR0301MB1653;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB1653; x-forefront-prvs: 079756C6B9 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(377454003)(24454002)(189002)(13464003)(199003)(377424004)(164054003)(102836003)(105586002)(10090500001)(1220700001)(586003)(93886004)(2501003)(1096002)(87936001)(86362001)(6116002)(86612001)(92566002)(99286002)(5004730100002)(74316001)(5008740100001)(2201001)(19580395003)(19580405001)(189998001)(101416001)(2950100001)(2900100001)(5001770100001)(76576001)(122556002)(54356999)(4001150100001)(76176999)(50986999)(561944003)(40100003)(11100500001)(33656002)(5890100001)(5003600100002)(81156007)(5001960100002)(106356001)(77096005)(5002640100001)(107886002)(8990500004)(97736004)(5005710100001)(10400500002)(106116001)(10290500002)(921003)(3826002)(1121003);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR0301MB1653;H:BY2PR0301MB1654.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2015 16:02:37.8264 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB1653 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tBLGHLU8004384 > -----Original Message----- > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com] > Sent: Friday, December 18, 2015 9:14 AM > To: Hannes Reinecke ; KY 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 > 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 {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 From: KY Srinivasan Subject: RE: [PATCH V3 2/4] scsi: storvsc: Properly support Fibre Channel devices Date: Mon, 21 Dec 2015 16:02:37 +0000 Message-ID: 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> <1450458820.2439.12.camel@HansenPartnership.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1450458820.2439.12.camel@HansenPartnership.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: James Bottomley , Hannes Reinecke , "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" List-Id: linux-scsi@vger.kernel.org > -----Original Message----- > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com] > Sent: Friday, December 18, 2015 9:14 AM > To: Hannes Reinecke ; KY 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 > 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