All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com,
	aliguori@amazon.com, amit.shah@redhat.com, "Chen,
	Tiejun" <tiejun.chen@intel.com>
Subject: Re: [Qemu-devel] [v2][RFC][PATCH] virtio: uniform virtio device IDs
Date: Wed, 11 Feb 2015 20:53:03 +0100	[thread overview]
Message-ID: <20150211195303.GI4623@redhat.com> (raw)
In-Reply-To: <20150211191022.57dba26a.cornelia.huck@de.ibm.com>

On Wed, Feb 11, 2015 at 07:10:22PM +0100, Cornelia Huck wrote:
> On Wed, 11 Feb 2015 13:41:29 +0100
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > On Mon, Feb 09, 2015 at 09:47:20AM +0100, Cornelia Huck wrote:
> 
> > > Well, we do need the changes in way more than two places, as every host
> > > or guest has to collect the definitions on its own, no?
> > 
> > This has nothing to do with host.
> 
> Hm, but all hosts and all guests need the ids, no?
> 
> > It's just using linux source as main basis for the file
> > simply because linux is a higher visibility project than qemu,
> > they won't borrow code from us but we can borrow from them.
> 
> It still seems restricting to use Linux as the ultimate source - and
> that has nothing to do with visibililty. I'd say pulling from any
> project is restricting: Why shouldn't we want to implement something in
> qemu that Linux is not (yet) interested in, but other guests are?

We can always add such a hypothetical feature in a qemu
specific headers.

But most things are shared, and manual duplication is bad.

> > > (Granted, with
> > > Linux and qemu you get most of the users; but it feels a bit strange
> > > for a host implementation to collect information from one of its
> > > guests. I really think that we should go back to the common root.
> > > Didn't we have a BSD-licenced header in the spec?)
> > 
> > virtio linux headers are also BSD licensed intentionally for this
> > purpose.
> >  * This header is BSD licensed so anyone can use the definitions to
> >  * implement compatible drivers/servers.
> 
> Sure, but I always took this to mean "you can freely copy the
> definitions", not "this is the authorative source".

virtio spec only has a ring header.
We could get it from there but it's easier to
get everything from one place I think.

-- 
MST

  reply	other threads:[~2015-02-11 19:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-06  5:41 [Qemu-devel] [v2][RFC][PATCH] virtio: uniform virtio device IDs Tiejun Chen
2015-02-06 12:14 ` Cornelia Huck
2015-02-08 10:48   ` Michael S. Tsirkin
2015-02-09  7:01     ` Chen, Tiejun
2015-02-09  7:02       ` Michael S. Tsirkin
2015-02-09  7:10         ` Chen, Tiejun
2015-02-09  8:47           ` Cornelia Huck
2015-02-11 12:41             ` Michael S. Tsirkin
2015-02-11 18:10               ` Cornelia Huck
2015-02-11 19:53                 ` Michael S. Tsirkin [this message]
2015-02-09  6:56   ` Chen, Tiejun
2015-02-06 16:28 ` Stefan Hajnoczi
2015-02-09  6:58   ` Chen, Tiejun
2015-02-09 19:57 ` Michael S. Tsirkin
2015-02-11 11:55   ` Amit Shah
2015-02-11 12:37     ` Michael S. Tsirkin
2015-02-11 11:18 ` Amit Shah

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=20150211195303.GI4623@redhat.com \
    --to=mst@redhat.com \
    --cc=agraf@suse.de \
    --cc=aliguori@amazon.com \
    --cc=amit.shah@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tiejun.chen@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.