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

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

From: Arnd Bergmann <arnd@arndb.de>
Date: 2010-05-05 20:10:34
Also in: lkml

On Wednesday 05 May 2010 19:47:10 Pankaj Thakkar wrote:
quoted
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?
We have the right number of module loaders in the kernel: one. If you
add another one, you're doubling the amount of code that anyone
working on that code needs to know about.
 
quoted
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 always be available.
Also we have to support windows and our current design supports it
nicely in an OS agnostic manner.
Your approach assumes that the plugin is always available, which has
exactly the same implications.
quoted
 (2) get rid of the whole shim crap and instead integrate the limited
     VF driver with the full VF driver we already have, instead of
     duplicating the code
[PT] Having a full VF driver adds a lot of dependency on the guest VM
and this is what NPA tries to avoid.
If you have the limited driver for some hardware that does not have
the real thing, we could still ship just that. I would however guess
that most vendors are interested in not just running in vmware but
also other hypervisors that still require the full driver, so that
case would be rare, especially in the long run.

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