public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Dmitry Torokhov <dtor@vmware.com>
Cc: "virtualization@lists.linux-foundation.org" 
	<virtualization@lists.linux-foundation.org>,
	Pankaj Thakkar <pthakkar@vmware.com>,
	Christoph Hellwig <hch@infradead.org>,
	"pv-drivers@vmware.com" <pv-drivers@vmware.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Pv-drivers] RFC: Network Plugin Architecture (NPA) for vmxnet3
Date: Wed, 5 May 2010 23:53:15 +0200	[thread overview]
Message-ID: <201005052353.16544.arnd@arndb.de> (raw)
In-Reply-To: <201005051336.32712.dtor@vmware.com>

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 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.
> 
> Since plugin[s] are carried by the host they are indeed always
> available.

But what makes you think that you can build code that can be linked
into arbitrary future kernel versions? The kernel does not define any
calling conventions that are stable across multiple versions or
configurations. For example, you'd have to provide different binaries
for each combination of

- 32/64 bit code
- gcc -mregparm=?
- lockdep
- tracepoints
- stackcheck
- NOMMU
- highmem
- whatever new gets merged

If you build the plugins only for specific versions of "enterprise" Linux
kernels, the code becomes really hard to debug and maintain.
If you wrap everything in your own version of the existing interfaces, your
code gets bloated to the point of being unmaintainable.

So I have to correct myself: this is very different from assuming the
driver is available in the guest, it's actually much worse.

	Arnd

  reply	other threads:[~2010-05-05 21:53 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-04 23:02 RFC: Network Plugin Architecture (NPA) for vmxnet3 Pankaj Thakkar
2010-05-05  0:05 ` Stephen Hemminger
2010-05-05  0:18   ` Pankaj Thakkar
2010-05-05  0:32     ` David Miller
2010-05-05  0:38       ` Pankaj Thakkar
2010-05-05  2:44     ` Stephen Hemminger
2010-05-05  0:58 ` Chris Wright
2010-05-05 19:00   ` Pankaj Thakkar
2010-05-05 17:23 ` Christoph Hellwig
2010-05-05 17:29   ` [Pv-drivers] " Dmitry Torokhov
2010-05-05 17:31     ` Christoph Hellwig
2010-05-05 17:35       ` Dmitry Torokhov
2010-05-05 17:39         ` Christoph Hellwig
2010-05-05 17:47           ` Pankaj Thakkar
2010-05-05 20:09             ` Arnd Bergmann
2010-05-05 20:36               ` Dmitry Torokhov
2010-05-05 21:53                 ` Arnd Bergmann [this message]
2010-05-05 22:05                   ` Shreyas Bhatewara
2010-05-06  2:03                     ` Scott Feldman
2010-05-06  7:25                       ` Shreyas Bhatewara
2010-05-06  7:25                       ` Shreyas Bhatewara
2010-05-06  8:19             ` Gleb Natapov
2010-05-06 18:04               ` Pankaj Thakkar
2010-05-06 20:19                 ` Christoph Hellwig
2010-05-06 20:17             ` Christoph Hellwig
2010-05-05 17:52           ` Stephen Hemminger
2010-05-06 20:21             ` Christoph Hellwig
2010-07-13  3:06               ` Shreyas Bhatewara
2010-07-13  5:16                 ` Stephen Hemminger
2010-07-14  0:31                 ` Stephen Hemminger
2010-07-14  9:49                 ` Greg KH
2010-07-14 17:18                   ` Pankaj Thakkar
2010-07-14 17:54                     ` David Miller
2010-07-14 18:03                       ` Jeremy Fitzhardinge
2010-07-14 20:20                     ` Greg KH
2010-07-14 17:19                   ` Shreyas Bhatewara
2010-07-14 20:42                   ` Shreyas Bhatewara
2010-07-14 21:06                     ` Greg KH
2010-05-05 17:59 ` Avi Kivity
2010-05-05 19:44   ` Pankaj Thakkar
2010-05-06  8:58     ` Avi Kivity
2010-05-10 20:46       ` Pankaj Thakkar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201005052353.16544.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=dtor@vmware.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pthakkar@vmware.com \
    --cc=pv-drivers@vmware.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox