Re: [PATCH 6/6] drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs
Greg has already asked you to resend. So here follow a few remarks to take into account for that resend. On Thu, 2015-06-11 at 16:22 +, ja...@microsoft.com wrote: --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig +config HYPERV_VPCI +tristate Hyper-V PCI Frontend +depends on PCI X86 HYPERV +select PCI_HV That symbol doesn't exist and is not added in this series, right? If so, scripts/checkkconsymbols.py could have told you that. +default y Are you sure? +help + The PCI device frontend driver allows the kernel to import arbitrary + PCI devices from a PCI backend to support PCI driver domains. --- /dev/null +++ b/drivers/pci/host/hv_pcifront.c + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or + * NON INFRINGEMENT. See the GNU General Public License for more This states the license is GPL v2. +EXPORT_SYMBOL(hv_read_config_block); +EXPORT_SYMBOL(hv_write_config_block); +EXPORT_SYMBOL(hv_register_block_invalidate); I couldn't spot any users of these exports. Actually, I couldn't even spot any users of these three functions. Why were they added? +MODULE_LICENSE(GPL); This states, according to include/linux/module.h, that the license is GPL v2 or later. So I think either the comment at the top of this file or the ident used in the MODULE_LICENSE() macro needs to change. Thanks, Paul Bolle ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 6/6] drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs
On Fri, Jun 12, 2015 at 03:11:14PM +, Jake Oshins wrote: This driver is intended to support both full PCI Express device pass through and also be the basis for SR-IOV networking on top of Hyper-V. These functions would allow somebody trying to make their NIC driver work on top of Hyper-V to exchange messages with their back-end Windows driver. My question is this. How does somebody delivering a platform usually work with the Linux community to deliver enablement code like this? I'm trying to work in the open, and go upstream early (or at least I think that understand what these things mean.) If the community doesn't want functions that have no callers (and I understand that, too) then how should I provide them to the NIC vendors? You add the functions in a patch series along with the NIC driver that uses it. We don't add functions with no callers, sorry. hope this helps, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 6/6] drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs
-Original Message- From: Paul Bolle [mailto:pebo...@tiscali.nl] Sent: Friday, June 12, 2015 1:44 AM To: Jake Oshins Cc: gre...@linuxfoundation.org; KY Srinivasan; linux- ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; linux-...@vger.kernel.org; bhelg...@google.com; Mike Ebersol; Haiyang Zhang Subject: Re: [PATCH 6/6] drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs Greg has already asked you to resend. So here follow a few remarks to take into account for that resend. Thank you. I'll fix everything you've mentioned before resending. I do have one more question, below. +EXPORT_SYMBOL(hv_read_config_block); +EXPORT_SYMBOL(hv_write_config_block); +EXPORT_SYMBOL(hv_register_block_invalidate); I couldn't spot any users of these exports. Actually, I couldn't even spot any users of these three functions. Why were they added? This driver is intended to support both full PCI Express device pass through and also be the basis for SR-IOV networking on top of Hyper-V. These functions would allow somebody trying to make their NIC driver work on top of Hyper-V to exchange messages with their back-end Windows driver. My question is this. How does somebody delivering a platform usually work with the Linux community to deliver enablement code like this? I'm trying to work in the open, and go upstream early (or at least I think that understand what these things mean.) If the community doesn't want functions that have no callers (and I understand that, too) then how should I provide them to the NIC vendors? Thanks, Jake Oshins ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 6/6] drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs
On Thu, Jun 11, 2015 at 04:22:27PM +, ja...@microsoft.com wrote: From: Jake Oshins ja...@microsoft.com drivers:pci:hv: Update MAINTAINERS Huh? drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs What is this odd format? Signed-off-by: Jake Oshins ja...@microsoft.com No blank line? Come on, you all know better than this... greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
