On Mon, Jul 12, 2010 at 08:06:28PM -0700, Shreyas Bhatewara wrote:
drivers/net/vmxnet3/vmxnet3_drv.c | 1845
+++--
Your patch is line-wrapped and can not be applied :(
Care to fix your email client?
One thing just jumped out at me when glancing at this:
On Wed, 14 Jul 2010, Greg KH wrote:
On Mon, Jul 12, 2010 at 08:06:28PM -0700, Shreyas Bhatewara wrote:
drivers/net/vmxnet3/vmxnet3_drv.c | 1845
+++--
Your patch is line-wrapped and can not be applied :(
Care to fix your email client?
One thing just
From: Pankaj Thakkar pthak...@vmware.com
Date: Wed, 14 Jul 2010 10:18:22 -0700
The plugin is guest agnostic and hence we did not want to rely on
any kernel provided functions.
While I disagree entirely with this kind of approach, even that
doesn't justify what you're doing here.
memcpy() and
On 07/14/2010 10:54 AM, David Miller wrote:
And doing what you're doing is foolish on so many levels. One more
duplication of code, one more place for unnecessary bugs to live, one
more place that might need optimizations and thus require duplication
of even more work people have done over
On Wed, Jul 14, 2010 at 10:18:22AM -0700, Pankaj Thakkar wrote:
The plugin is guest agnostic and hence we did not want to rely on any
kernel provided functions. The plugin uses only the interface provided
by the shell.
Really? vmxnet3_plugin.c is no supposed to use any kernel-provided
On Wed, Jul 14, 2010 at 01:42:59PM -0700, Shreyas Bhatewara wrote:
+/* vmkernel and device backend shared definitions */
+
+#define VMXNET3_PLUGIN_NAME_LEN 256
+#define VMXNET3_PLUGIN_REPOSITORY /usr/lib/vmware/npa_plugins
Why would the kernel care about this file path? And since when do we
On Mon, 12 Jul 2010 20:06:28 -0700
Shreyas Bhatewara sbhatew...@vmware.com wrote:
On Thu, 2010-05-06 at 13:21 -0700, Christoph Hellwig wrote:
On Wed, May 05, 2010 at 10:52:53AM -0700, Stephen Hemminger wrote:
Let me put it bluntly. Any design that allows external code to run
in the
On Mon, 12 Jul 2010 20:06:28 -0700
Shreyas Bhatewara sbhatew...@vmware.com wrote:
On Thu, 2010-05-06 at 13:21 -0700, Christoph Hellwig wrote:
On Wed, May 05, 2010 at 10:52:53AM -0700, Stephen Hemminger wrote:
Let me put it bluntly. Any design that allows external code to run
in the
...@lists.linux-
foundation.org; Pankaj Thakkar
Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for
vmxnet3
On 5/5/10 10:29 AM, Dmitry Torokhov d...@vmware.com wrote:
It would not be a binary blob but software properly released under
GPL.
The current plan is for the shell
On Thu, May 06, 2010 at 01:19:33AM -0700, Gleb Natapov wrote:
Overhead of interpreting bytecode plugin is written in. Or are you
saying plugin is x86 assembly (32bit or 64bit btw?) and other arches
will have to have in kernel x86 emulator to use the plugin (like some
of them had for vgabios)?
On Wed, May 05, 2010 at 10:47:10AM -0700, Pankaj Thakkar wrote:
Forget about the licensing. Loading binary blobs written to a shim
layer is a complete pain in the ass and totally unsupportable, and
also uninteresting because of the overhead.
[PT] Why do you think it is unsupportable? How
On Wed, May 05, 2010 at 10:52:53AM -0700, Stephen Hemminger wrote:
Let me put it bluntly. Any design that allows external code to run
in the kernel is not going to be accepted. Out of tree kernel modules are
enough
of a pain already, why do you expect the developers to add another
-foundation.org
virtualization@lists.linux-foundation.org,
pv-driv...@vmware.com pv-driv...@vmware.com,
Shreyas Bhatewara sbhatew...@vmware.com
Subject: Re: RFC: Network Plugin Architecture (NPA) for vmxnet3
On Tue, 4 May 2010 16:02:25 -0700
Pankaj Thakkar pthak...@vmware.com wrote
-foundation.org
virtualization@lists.linux-foundation.org,
pv-driv...@vmware.com pv-driv...@vmware.com,
Shreyas Bhatewara sbhatew...@vmware.com
Subject: Re: RFC: Network Plugin Architecture (NPA) for vmxnet3
From: Pankaj Thakkar pthak...@vmware.com
Date: Tue, 4 May 2010 17:18:57 -0700
On Tue, May 04, 2010 at 04:02:25PM -0700, Pankaj Thakkar wrote:
The plugin image is provided by the IHVs along with the PF driver and is
packaged in the hypervisor. The plugin image is OS agnostic and can be loaded
either into a Linux VM or a Windows VM. The plugin is written against the
On Wed, May 05, 2010 at 10:35:28AM -0700, Dmitry Torokhov wrote:
Yes, with the exception that the only body of code that will be
accepted by the shell should be GPL-licensed and thus open and available
for examining. This is not different from having a standard kernel
module that is loaded
-foundation.org
Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for
vmxnet3
On Wed, May 05, 2010 at 10:35:28AM -0700, Dmitry Torokhov wrote:
Yes, with the exception that the only body of code that will be
accepted by the shell should be GPL-licensed and thus open and
available
,
virtualization@lists.linux-foundation.org
virtualization@lists.linux-foundation.org,
pv-driv...@vmware.com pv-driv...@vmware.com,
Shreyas Bhatewara sbhatew...@vmware.com,
k...@vger.kernel.org k...@vger.kernel.org
Subject: Re: RFC: Network Plugin Architecture (NPA
,
virtualization@lists.linux-foundation.org
virtualization@lists.linux-foundation.org,
pv-driv...@vmware.com pv-driv...@vmware.com,
Shreyas Bhatewara sbhatew...@vmware.com
Subject: Re: RFC: Network Plugin Architecture (NPA) for vmxnet3
On 05/05/2010 02:02 AM, Pankaj Thakkar wrote
On Wednesday 05 May 2010 19:47:10 Pankaj Thakkar wrote:
Forget about the licensing. Loading binary blobs written to a shim
layer is a complete pain in the ass and totally unsupportable, and
also uninteresting because of the overhead.
[PT] Why do you think it is unsupportable? How
On Wednesday 05 May 2010 22:36:31 Dmitry Torokhov wrote:
On Wednesday 05 May 2010 01:09:48 pm Arnd Bergmann wrote:
If you have any interesting in developing this further, do:
(1) move the limited VF drivers directly into the kernel tree,
talk to them through a normal ops
On Wednesday 05 May 2010 10:23:16 am Christoph Hellwig wrote:
On Tue, May 04, 2010 at 04:02:25PM -0700, Pankaj Thakkar wrote:
The plugin image is provided by the IHVs along with the PF driver and is
packaged in the hypervisor. The plugin image is OS agnostic and can be
loaded either into a
On Wednesday 05 May 2010 10:31:20 am Christoph Hellwig wrote:
On Wed, May 05, 2010 at 10:29:40AM -0700, Dmitry Torokhov wrote:
We're not going to add any kind of loader for binry blobs into kernel
space, sorry. Don't even bother wasting your time on this.
It would not be a binary blob
On Wednesday 05 May 2010 01:09:48 pm Arnd Bergmann wrote:
If you have any interesting in developing this further, do:
(1) move the limited VF drivers directly into the kernel tree,
talk to them through a normal ops vector
[PT] This assumes that all the VF drivers would
* Pankaj Thakkar (pthak...@vmware.com) wrote:
We intend to upgrade the upstreamed vmxnet3 driver to implement NPA so that
Linux users can exploit the benefits provided by passthrough devices in a
seamless manner while retaining the benefits of virtualization. The document
below tries to answer
25 matches
Mail list logo
