Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
On Thu, 25 Oct 2012, Jan Beulich wrote: On 24.10.12 at 23:33, Randy Dunlap rdun...@xenotime.net wrote: On 10/23/2012 09:19 PM, Stephen Rothwell wrote: Hi all, Changes since 201201023: on x86_64: drivers/built-in.o: In function `dbgp_reset_prep': (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep' drivers/built-in.o: In function `dbgp_external_startup': (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup' Full randconfig file is attached. So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP dbgp_reset_prep() and dbgp_external_startup() get pointlessly defined and exported. This got broken by the merge recommendation for the ARM side changes (originally compilation of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0). From my pov, fixing the USB side would be the clean solution (i.e. putting those function definitions inside a CONFIG_USB_SUPPORT conditional). The alternative of a smaller change would be to extend the conditional around the respective xen_dbgp_...() declarations in include/linux/usb/ehci_def.h to become #if defined(CONFIG_XEN_DOM0) defined(CONFIG_USB_SUPPORT) Please advise towards your preference. I think that your first suggestion is the right one. Otherwise we could also make drivers/xen/dbgp.c compile if CONFIG_EARLY_PRINTK_DBGP rather than CONFIG_USB_SUPPORT. I think that it would create fewer maintenance pains if dbgp_reset_prep and dbgp_external_startup had the same compile requirements as their xen counterparts (aside from Xen support of course). ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
On 25.10.12 at 15:46, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote: On Thu, 25 Oct 2012, Jan Beulich wrote: On 24.10.12 at 23:33, Randy Dunlap rdun...@xenotime.net wrote: On 10/23/2012 09:19 PM, Stephen Rothwell wrote: Hi all, Changes since 201201023: on x86_64: drivers/built-in.o: In function `dbgp_reset_prep': (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep' drivers/built-in.o: In function `dbgp_external_startup': (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup' Full randconfig file is attached. So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP dbgp_reset_prep() and dbgp_external_startup() get pointlessly defined and exported. This got broken by the merge recommendation for the ARM side changes (originally compilation of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0). From my pov, fixing the USB side would be the clean solution (i.e. putting those function definitions inside a CONFIG_USB_SUPPORT conditional). The alternative of a smaller change would be to extend the conditional around the respective xen_dbgp_...() declarations in include/linux/usb/ehci_def.h to become #if defined(CONFIG_XEN_DOM0) defined(CONFIG_USB_SUPPORT) Please advise towards your preference. I think that your first suggestion is the right one. Can you guys spin up a patch pls and make sure it does not break compilation. Thx. I'd really like to hear Greg's opinion on which route to take before pointlessly trying the other one. Jan ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote: On Thu, 25 Oct 2012, Jan Beulich wrote: On 24.10.12 at 23:33, Randy Dunlap rdun...@xenotime.net wrote: On 10/23/2012 09:19 PM, Stephen Rothwell wrote: Hi all, Changes since 201201023: on x86_64: drivers/built-in.o: In function `dbgp_reset_prep': (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep' drivers/built-in.o: In function `dbgp_external_startup': (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup' Full randconfig file is attached. So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP dbgp_reset_prep() and dbgp_external_startup() get pointlessly defined and exported. This got broken by the merge recommendation for the ARM side changes (originally compilation of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0). From my pov, fixing the USB side would be the clean solution (i.e. putting those function definitions inside a CONFIG_USB_SUPPORT conditional). The alternative of a smaller change would be to extend the conditional around the respective xen_dbgp_...() declarations in include/linux/usb/ehci_def.h to become #if defined(CONFIG_XEN_DOM0) defined(CONFIG_USB_SUPPORT) Please advise towards your preference. I think that your first suggestion is the right one. Can you guys spin up a patch pls and make sure it does not break compilation. Thx. Otherwise we could also make drivers/xen/dbgp.c compile if CONFIG_EARLY_PRINTK_DBGP rather than CONFIG_USB_SUPPORT. I think that it would create fewer maintenance pains if dbgp_reset_prep and dbgp_external_startup had the same compile requirements as their xen counterparts (aside from Xen support of course). ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
On Thu, Oct 25, 2012 at 03:05:43PM +0100, Jan Beulich wrote: On 25.10.12 at 15:46, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote: On Thu, 25 Oct 2012, Jan Beulich wrote: On 24.10.12 at 23:33, Randy Dunlap rdun...@xenotime.net wrote: On 10/23/2012 09:19 PM, Stephen Rothwell wrote: Hi all, Changes since 201201023: on x86_64: drivers/built-in.o: In function `dbgp_reset_prep': (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep' drivers/built-in.o: In function `dbgp_external_startup': (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup' Full randconfig file is attached. So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP dbgp_reset_prep() and dbgp_external_startup() get pointlessly defined and exported. This got broken by the merge recommendation for the ARM side changes (originally compilation of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0). From my pov, fixing the USB side would be the clean solution (i.e. putting those function definitions inside a CONFIG_USB_SUPPORT conditional). The alternative of a smaller change would be to extend the conditional around the respective xen_dbgp_...() declarations in include/linux/usb/ehci_def.h to become #if defined(CONFIG_XEN_DOM0) defined(CONFIG_USB_SUPPORT) Please advise towards your preference. I think that your first suggestion is the right one. Can you guys spin up a patch pls and make sure it does not break compilation. Thx. I'd really like to hear Greg's opinion on which route to take before pointlessly trying the other one. I have no idea, please send patches. greg k-h ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 04/10] VMCI: device driver implementaton.
On Mon, Oct 15, 2012 at 05:28:47PM -0700, George Zhang wrote:
+/*
+ * vmci_device_get() - Checks for VMCI device.
+ * @api_version:The API version to use
+ * @device_shutdown_cb: Callback used when shutdown happens (Unused)
+ * @user_data: Data to be passed to the callback (Unused)
+ * @device_registration:A device registration handle. (Unused)
+ *
+ * Verifies that a valid VMCI device is present, and indicates
+ * the callers intention to use the device until it calls
+ * vmci_device_release().
+ */
+bool vmci_device_get(u32 *api_version,
+ vmci_device_shutdown_fn *device_shutdown_cb,
+ void *user_data, void **device_registration)
+{
+ if (*api_version VMCI_KERNEL_API_VERSION) {
+ *api_version = VMCI_KERNEL_API_VERSION;
+ return false;
+ }
+
+ return drv_device_enabled();
+}
+EXPORT_SYMBOL(vmci_device_get);
EXPORT_SYMBOL_GPL() for this, and all other exports?
And it seems that you have a bunch of unused parameters for this, and
other public functions. Please just remove them entirely, otherwise it
just confuses reviewers, and anyone who wants to write code to interface
with the code. You can always add parameters at a later point in time
if you find that you really need them.
thanks,
greg k-h
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 04/10] VMCI: device driver implementaton.
Hi Greg, +EXPORT_SYMBOL(vmci_device_get); EXPORT_SYMBOL_GPL() for this, and all other exports? We'd prefer to leave them as vanilla exports. While we're committed to open-sourcing everything, including our non-upstreamed drivers, we don't really have a strong opinion regarding consuming our exports in closed-source (general GPL issues aside). And it seems that you have a bunch of unused parameters for this, and other public functions. Please just remove them entirely. Will do. Also, regarding that particular public function, it seems to have slipped through the cracks. It's an artifact of the API being cross-platform prior to upstreaming. On Linux, it makes no sense whatsoever, so we'll just yank it completely. Thanks! - Andy ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 04/10] VMCI: device driver implementaton.
On Thu, Oct 25, 2012 at 01:16:00PM -0700, Andy King wrote: Hi Greg, +EXPORT_SYMBOL(vmci_device_get); EXPORT_SYMBOL_GPL() for this, and all other exports? We'd prefer to leave them as vanilla exports. While we're committed to open-sourcing everything, including our non-upstreamed drivers, we don't really have a strong opinion regarding consuming our exports in closed-source (general GPL issues aside). You can't just say general GPL issues aside. Honestly, given your company's prior actions in regards to Linux kernel drivers and the licenses of them, I don't trust them at all. To help gain that trust back, marking the exports in this manner will be a great improvement. To insist otherwise is to only reinforce my doubts, and reduce my wanting to even review or accept this code at all. Sorry about that. And it seems that you have a bunch of unused parameters for this, and other public functions. Please just remove them entirely. Will do. Also, regarding that particular public function, it seems to have slipped through the cracks. It's an artifact of the API being cross-platform prior to upstreaming. On Linux, it makes no sense whatsoever, so we'll just yank it completely. What other calls can be removed? Did you run sparse on all of these files to ensure that things are clean with regards to static functions and the like? thanks, greg k-h ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 04/10] VMCI: device driver implementaton.
Hi Greg, You can't just say general GPL issues aside. Honestly, given your company's prior actions in regards to Linux kernel drivers and the licenses of them, I don't trust them at all. To help gain that trust back, marking the exports in this manner will be a great improvement. You don't expect us to just let that comment slide :) Can you be more specific about which prior actions in regards to which kernel drivers, and when? We certainly don't want the Linux kernel community, especially somebody as influential as you, to lack trust in VMware or our intentions. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 04/10] VMCI: device driver implementaton.
On Thursday, October 25, 2012 01:31:48 PM Greg KH wrote: On Thu, Oct 25, 2012 at 01:16:00PM -0700, Andy King wrote: Hi Greg, +EXPORT_SYMBOL(vmci_device_get); EXPORT_SYMBOL_GPL() for this, and all other exports? We'd prefer to leave them as vanilla exports. While we're committed to open-sourcing everything, including our non-upstreamed drivers, we don't really have a strong opinion regarding consuming our exports in closed-source (general GPL issues aside). You can't just say general GPL issues aside. Honestly, given your company's prior actions in regards to Linux kernel drivers and the licenses of them, I don't trust them at all. To help gain that trust back, marking the exports in this manner will be a great improvement. To insist otherwise is to only reinforce my doubts, and reduce my wanting to even review or accept this code at all. Sorry about that. Huh? What are the concerns exactly? I do not really see difference between EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(). The code either derivative of the kernel or it is not and so it either falls under the kernel license or not. From out perspective we do not really care what other code might use VMCI, all our Linux drivers, even if not all are upstream [yet], are GPL. Thanks, Dmitry ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 04/10] VMCI: device driver implementaton.
On Thu, Oct 25, 2012 at 01:43:50PM -0700, Bhavesh Davda wrote: Hi Greg, You can't just say general GPL issues aside. Honestly, given your company's prior actions in regards to Linux kernel drivers and the licenses of them, I don't trust them at all. To help gain that trust back, marking the exports in this manner will be a great improvement. You don't expect us to just let that comment slide :) Can you be more specific about which prior actions in regards to which kernel drivers, and when? For many many years, you shipped closed source Linux kernel drivers for your products. Only recently has this changed. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 04/10] VMCI: device driver implementaton.
On Thu, Oct 25, 2012 at 01:45:39PM -0700, Dmitry Torokhov wrote: On Thursday, October 25, 2012 01:31:48 PM Greg KH wrote: On Thu, Oct 25, 2012 at 01:16:00PM -0700, Andy King wrote: Hi Greg, +EXPORT_SYMBOL(vmci_device_get); EXPORT_SYMBOL_GPL() for this, and all other exports? We'd prefer to leave them as vanilla exports. While we're committed to open-sourcing everything, including our non-upstreamed drivers, we don't really have a strong opinion regarding consuming our exports in closed-source (general GPL issues aside). You can't just say general GPL issues aside. Honestly, given your company's prior actions in regards to Linux kernel drivers and the licenses of them, I don't trust them at all. To help gain that trust back, marking the exports in this manner will be a great improvement. To insist otherwise is to only reinforce my doubts, and reduce my wanting to even review or accept this code at all. Sorry about that. Huh? What are the concerns exactly? I do not really see difference between EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(). The code either derivative of the kernel or it is not and so it either falls under the kernel license or not. I totally agree. In this case, do you think it falls under the kernel license or not? From out perspective we do not really care what other code might use VMCI, all our Linux drivers, even if not all are upstream [yet], are GPL. That's nice to hear, although without proof of that, we have to take your word :) thanks, greg k-h ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 04/10] VMCI: device driver implementaton.
Hi Greg, You can't just say general GPL issues aside. Honestly, given your company's prior actions in regards to Linux kernel drivers and the licenses of them, I don't trust them at all. To help gain that trust back, marking the exports in this manner will be a great improvement. To insist otherwise is to only reinforce my doubts, and reduce my wanting to even review or accept this code at all. Sorry about that. That's perfectly fair. In the interest of gaining back some of that trust, we'll be more than happy to make the exports GPL. Expect a diff in the next few days with that change along with any modifications necessary after a sparse sanity check. Thanks! - Andy PS I finally remembered to drop vm-crosstalk, so hopefully you won't get anymore annoying bounces. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 04/10] VMCI: device driver implementaton.
On Thursday, October 25, 2012 02:04:48 PM Greg KH wrote: On Thu, Oct 25, 2012 at 01:45:39PM -0700, Dmitry Torokhov wrote: On Thursday, October 25, 2012 01:31:48 PM Greg KH wrote: On Thu, Oct 25, 2012 at 01:16:00PM -0700, Andy King wrote: Hi Greg, +EXPORT_SYMBOL(vmci_device_get); EXPORT_SYMBOL_GPL() for this, and all other exports? We'd prefer to leave them as vanilla exports. While we're committed to open-sourcing everything, including our non-upstreamed drivers, we don't really have a strong opinion regarding consuming our exports in closed-source (general GPL issues aside). You can't just say general GPL issues aside. Honestly, given your company's prior actions in regards to Linux kernel drivers and the licenses of them, I don't trust them at all. To help gain that trust back, marking the exports in this manner will be a great improvement. To insist otherwise is to only reinforce my doubts, and reduce my wanting to even review or accept this code at all. Sorry about that. Huh? What are the concerns exactly? I do not really see difference between EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(). The code either derivative of the kernel or it is not and so it either falls under the kernel license or not. I totally agree. In this case, do you think it falls under the kernel license or not? VMCI implementation that we are submitting is GPL as witnessed by the license notices on the source files ;) From out perspective we do not really care what other code might use VMCI, all our Linux drivers, even if not all are upstream [yet], are GPL. That's nice to hear, although without proof of that, we have to take your word :) The source to Open VM Tools (which includes guest drivers that have not been upstreamed yet) can be always found here: https://sourceforge.net/projects/open-vm-tools/files/ and here: git.opensource.vmware.com/opensource/open-vm-tools/ The hosted drivers are distributed in source form with the product and here: https://my.vmware.com/web/vmware/info/slug/desktop_end_user_computing/vmware_workstation/9_0#open_source Thanks, Dmitry thanks, greg k-h ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 04/10] VMCI: device driver implementaton.
On Thursday, October 25, 2012 02:03:20 PM Greg KH wrote: On Thu, Oct 25, 2012 at 01:43:50PM -0700, Bhavesh Davda wrote: Hi Greg, You can't just say general GPL issues aside. Honestly, given your company's prior actions in regards to Linux kernel drivers and the licenses of them, I don't trust them at all. To help gain that trust back, marking the exports in this manner will be a great improvement. You don't expect us to just let that comment slide :) Can you be more specific about which prior actions in regards to which kernel drivers, and when? For many many years, you shipped closed source Linux kernel drivers for your products. Only recently has this changed. That was in the past. As far as I know our Linux drivers have been open for more than 5 years, so not that recently. Thanks, Dmitry ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [Pv-drivers] [PATCH 04/10] VMCI: device driver implementaton.
For many many years, you shipped closed source Linux kernel drivers for your products. Only recently has this changed. and all our Linux drivers, even if not all are upstream [yet], are GPL. That's nice to hear, although without proof of that, we have to take your word :) The following VMware drivers are in mainline Linux now (thanks to you and other members of the kernel community for that!) vmxnet3: Tue Oct 13 00:15:51 2009 -0700 vmw_pvscsi: Tue Oct 13 14:51:05 2009 -0700 vmwgfx: Thu Dec 10 00:19:58 2009 + vmw_balloon: Fri Apr 23 13:18:08 2010 -0400 Thanks - Bhavesh ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
