Thread (42 messages) 42 messages, 13 authors, 2010-07-14

Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3

From: Gleb Natapov <hidden>
Date: 2010-05-06 08:19:51
Also in: lkml

On Wed, May 05, 2010 at 10:47:10AM -0700, Pankaj Thakkar wrote:
quoted
-----Original Message-----
From: Christoph Hellwig [mailto:hch@infradead.org]
Sent: Wednesday, May 05, 2010 10:40 AM
To: Dmitry Torokhov
Cc: Christoph Hellwig; pv-drivers@vmware.com; Pankaj Thakkar;
netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
virtualization@lists.linux-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:
quoted
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
quoted
for examining. This is not different from having a standard kernel
module that is loaded normally and plugs into a certain subsystem.
The difference is that the binary resides not on guest filesystem
but elsewhere.
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 different is it from any module
written against a well maintained interface? What overhead are you talking about?
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)? 

--
			Gleb.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help