From: KY Srinivasan <kys@microsoft.com> To: James Bottomley <James.Bottomley@HansenPartnership.com>, Hannes Reinecke <hare@suse.de>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>, "ohering@suse.com" <ohering@suse.com>, "jbottomley@parallels.com" <jbottomley@parallels.com>, "hch@infradead.org" <hch@infradead.org>, "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>, "apw@canonical.com" <apw@canonical.com>, "vkuznets@redhat.com" <vkuznets@redhat.com>, "jasowang@redhat.com" <jasowang@redhat.com>, "martin.petersen@oracle.com" <martin.petersen@oracle.com> Subject: RE: [PATCH V3 2/4] scsi: storvsc: Properly support Fibre Channel devices Date: Mon, 21 Dec 2015 16:02:37 +0000 [thread overview] Message-ID: <BY2PR0301MB16545E8967AA1D206D101754A0E40@BY2PR0301MB1654.namprd03.prod.outlook.com> (raw) In-Reply-To: <1450458820.2439.12.camel@HansenPartnership.com> > -----Original Message----- > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com] > Sent: Friday, December 18, 2015 9:14 AM > To: Hannes Reinecke <hare@suse.de>; KY Srinivasan <kys@microsoft.com>; > 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
WARNING: multiple messages have this Message-ID (diff)
From: KY Srinivasan <kys@microsoft.com> To: James Bottomley <James.Bottomley@HansenPartnership.com>, Hannes Reinecke <hare@suse.de>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>, "ohering@suse.com" <ohering@suse.com>, "jbottomley@parallels.com" <jbottomley@parallels.com>, "hch@infradead.org" <hch@infradead.org>, "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>, "apw@canonical.com" <apw@canonical.com>, "vkuznets@redhat.com" <vkuznets@redhat.com>, "jasowang@redhat.com" <jasowang@redhat.com>, "martin.petersen@oracle.com" <martin.petersen@oracle.com> Subject: RE: [PATCH V3 2/4] scsi: storvsc: Properly support Fibre Channel devices Date: Mon, 21 Dec 2015 16:02:37 +0000 [thread overview] Message-ID: <BY2PR0301MB16545E8967AA1D206D101754A0E40@BY2PR0301MB1654.namprd03.prod.outlook.com> (raw) In-Reply-To: <1450458820.2439.12.camel@HansenPartnership.com> [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2315 bytes --] > -----Original Message----- > From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com] > Sent: Friday, December 18, 2015 9:14 AM > To: Hannes Reinecke <hare@suse.de>; KY Srinivasan <kys@microsoft.com>; > 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Ç+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
next prev parent reply other threads:[~2015-12-21 16:02 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-12-13 20:28 [PATCH V3 0/4] scsi: storvsc: Properly support FC hosts K. Y. Srinivasan 2015-12-13 20:28 ` [PATCH V3 1/4] scsi: storvsc: Fix a bug in the layout of the hv_fc_wwn_packet K. Y. Srinivasan 2015-12-13 20:28 ` K. Y. Srinivasan 2015-12-13 20:28 ` [PATCH V3 2/4] scsi: storvsc: Properly support Fibre Channel devices K. Y. Srinivasan 2015-12-13 20:28 ` K. Y. Srinivasan 2015-12-18 8:49 ` Hannes Reinecke 2015-12-18 17:13 ` KY Srinivasan 2015-12-18 17:13 ` James Bottomley 2015-12-21 16:02 ` KY Srinivasan [this message] 2015-12-21 16:02 ` KY Srinivasan 2015-12-13 20:28 ` [PATCH V3 3/4] scsi: storvsc: Refactor the code in storvsc_channel_init() K. Y. Srinivasan 2015-12-13 20:28 ` K. Y. Srinivasan 2015-12-18 8:50 ` Hannes Reinecke 2015-12-18 8:50 ` Hannes Reinecke 2015-12-13 20:28 ` [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path K. Y. Srinivasan 2015-12-13 20:28 ` K. Y. Srinivasan 2015-12-18 8:51 ` Hannes Reinecke 2015-12-18 16:20 ` KY Srinivasan 2015-12-18 16:48 ` James Bottomley 2015-12-19 2:28 ` KY Srinivasan 2015-12-19 2:28 ` KY Srinivasan 2015-12-21 7:42 ` Hannes Reinecke 2015-12-21 7:42 ` Hannes Reinecke 2015-12-21 16:28 ` James Bottomley 2015-12-21 19:40 ` KY Srinivasan 2015-12-21 19:40 ` KY Srinivasan 2015-12-18 8:40 ` [PATCH V3 1/4] scsi: storvsc: Fix a bug in the layout of the hv_fc_wwn_packet Hannes Reinecke
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=BY2PR0301MB16545E8967AA1D206D101754A0E40@BY2PR0301MB1654.namprd03.prod.outlook.com \ --to=kys@microsoft.com \ --cc=James.Bottomley@HansenPartnership.com \ --cc=apw@canonical.com \ --cc=devel@linuxdriverproject.org \ --cc=gregkh@linuxfoundation.org \ --cc=hare@suse.de \ --cc=hch@infradead.org \ --cc=jasowang@redhat.com \ --cc=jbottomley@parallels.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=ohering@suse.com \ --cc=vkuznets@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.