public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Andy King <acking@vmware.com>
Cc: linux-kernel@vger.kernel.org, dtor@vmware.com,
	dsouders@vmware.com, cschamp@vmware.com,
	akpm@linux-foundation.org,
	virtualization@lists.linux-foundation.org,
	"Andrew Stiegmann (stieg)" <astiegmann@vmware.com>
Subject: Re: [vmw_vmci RFC 00/11] VMCI for Linux
Date: Mon, 4 Jun 2012 15:57:57 -0700	[thread overview]
Message-ID: <20120604225757.GC7041@kroah.com> (raw)
In-Reply-To: <552579991.43606.1338564781979.JavaMail.root@vmware.com>

On Fri, Jun 01, 2012 at 08:33:02AM -0700, Andy King wrote:
> Greg,
> 
> Thanks so much for the comments and apologies for the delayed response.
> 
> > Don't we have something like this already for KVM and maybe Xen?
> > virtio?  Can't you use that code instead of a new block of code that
> > is only used by vmware users?  It has virtual pci devices which
> > should give you what you want/need here, right?
> >
> > If not, why doesn't that work for you?  Would it be easier to just
> > extend it?
> 
> The VMCI virtual device for which this driver is intended has been
> around a lot longer than this submission might suggest.  The virtual
> hardware was released in a product before Rusty sent his RFC and
> quite a bit before it made it to mainline; there was, regrettably,
> no virtio then.
> 
> As such, it was designed to be its own transport, and it's something
> that is now very much fixed at the hardware level (enhancements
> not withstanding), and which we have to support all the way back.

What "hardware" are you refering to here?

> In addition to that, our hypervisor endpoints are written using
> the existing device backend; virtio doesn't currently make a lot of
> sense for them, and would require a lot of additional work.
> 
> All of this is unfortunate.  While I agree that virtio is certainly
> the right approach, and we need to avoid this proliferation, I think
> at this point we'd really like to try and upstream this in its current
> form.  There's certainly the possibility going forwards that we could
> add a glue layer, such that other clients could use virtio if they're
> willing to write their own hypervisor endpoints.
> 
> Does that sound reasonable?

Not really, why should we take an interface that is tied to something
that you are saying isn't something we should be using?  Don't you also
have control over the hypervisor side of things in order to properly
design this type of thing?

thanks,

greg k-h

  reply	other threads:[~2012-06-05  6:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-15 15:06 [vmw_vmci RFC 00/11] VMCI for Linux Andrew Stiegmann (stieg)
2012-05-15 15:06 ` [vmw_vmci RFC 01/11] Apply VMCI context code Andrew Stiegmann (stieg)
2012-05-15 23:47   ` Greg KH
2012-05-16 17:01   ` Stephen Hemminger
2012-05-16 18:34     ` Andrew Stiegmann
2012-05-15 15:06 ` [vmw_vmci RFC 02/11] Apply VMCI datagram code Andrew Stiegmann (stieg)
2012-05-15 15:07 ` [vmw_vmci RFC 03/11] Apply VMCI doorbell code Andrew Stiegmann (stieg)
2012-05-15 15:07 ` [vmw_vmci RFC 04/11] Apply VMCI driver code Andrew Stiegmann (stieg)
2012-05-15 15:07 ` [vmw_vmci RFC 05/11] Apply VMCI event code Andrew Stiegmann (stieg)
2012-05-15 15:07 ` [vmw_vmci RFC 06/11] Apply dynamic array code Andrew Stiegmann (stieg)
2012-05-15 15:07 ` [vmw_vmci RFC 07/11] Apply VMCI hash table Andrew Stiegmann (stieg)
2012-05-15 15:07 ` [vmw_vmci RFC 08/11] Apply VMCI queue pairs Andrew Stiegmann (stieg)
2012-05-15 15:07 ` [vmw_vmci RFC 09/11] Apply VMCI resource code Andrew Stiegmann (stieg)
2012-05-15 15:07 ` [vmw_vmci RFC 10/11] Apply vmci routing code Andrew Stiegmann (stieg)
2012-05-15 15:07 ` [vmw_vmci RFC 11/11] Apply the header code to make VMCI build Andrew Stiegmann (stieg)
2012-05-15 23:50 ` [vmw_vmci RFC 00/11] VMCI for Linux Greg KH
2012-05-16  8:55   ` Dor Laor
2012-06-01 15:33   ` Andy King
2012-06-04 22:57     ` Greg KH [this message]
2012-06-05  7:02       ` Dmitry Torokhov
2012-06-06  5:06         ` Greg KH
2012-06-14 11:52           ` Dor Laor

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=20120604225757.GC7041@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=acking@vmware.com \
    --cc=akpm@linux-foundation.org \
    --cc=astiegmann@vmware.com \
    --cc=cschamp@vmware.com \
    --cc=dsouders@vmware.com \
    --cc=dtor@vmware.com \
    --cc=linux-kernel@vger.kernel.org \
    --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