From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>,
"Chen, Tiejun" <tiejun.chen@intel.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Stefan Hajnoczi <stefanha@redhat.com>,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH RFC] scripts/update-linux-headers.sh: pull virtio hdrs
Date: Wed, 11 Feb 2015 13:28:18 +0100 [thread overview]
Message-ID: <20150211122818.GB4623@redhat.com> (raw)
In-Reply-To: <CAFEAcA8Fa8_N1kVXV5S9v03r0DKYf3Tb=w3sr_jLu+k-+u0M1A@mail.gmail.com>
On Wed, Feb 11, 2015 at 03:46:20AM +0000, Peter Maydell wrote:
> On 11 February 2015 at 02:50, Chen, Tiejun <tiejun.chen@intel.com> wrote:
> > On 2015/2/11 10:03, Peter Maydell wrote:
> >> The linux-headers/ directory contains header files which can only
> >> validly be included if the host we're compiling on is Linux. Some
> >> of them will cause compile failures on OSX or Windows if they
> >> are in the include path. The idea of this patch is that the
> >> standard-headers/ directory has "sanitized" header files which
> >> have had the linux-specific types and includes stripped out.
> >> So if we take the route this patch proposes we do need two
> >> directories.
> >>
> >
> > This confounds me since for instance, one of goals based on this patch is,
> > it exposes those Virtio devices ID definition to hw/virtio, instead of my
> > original patch, right? So without this sort of standard-hearders, how can we
> > compile virtio? Or you mean we still keep those original stuff in
> > include/hw/virtio*, but somehow update them once we execute that script
> > manually.
>
> I'm confused about why you're confused. We have two basic
> approaches we can take:
>
> (1) What we do at the moment. There are headers defining the virtio
> interface in include/hw/virtio, and these are basically manually
> created and updated as necessary.
>
> (2) What this patch is proposing. The headers defining virtio are
> automatically copied into standard-headers/ and fixed up to make
> them work with QEMU on all the hosts we support. This happens when
> this script is run by a developer to update QEMU's headers based
> on some new upstream kernel.
>
> Personally I think that option 1 is more reliable and overall
> less effort, since automatiing the fixups is hard and virtio
> doesn't change very much.
>
> -- PMM
It picked up speed recently, so it's too much effort I think.
My script seems to have automated fixups - didn't seem hard.
--
MST
next prev parent reply other threads:[~2015-02-11 12:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-09 19:56 [Qemu-devel] [PATCH RFC] scripts/update-linux-headers.sh: pull virtio hdrs Michael S. Tsirkin
2015-02-11 1:36 ` Chen, Tiejun
2015-02-11 2:03 ` Peter Maydell
2015-02-11 2:50 ` Chen, Tiejun
2015-02-11 3:46 ` Peter Maydell
2015-02-11 8:08 ` Chen, Tiejun
2015-02-11 12:28 ` Michael S. Tsirkin [this message]
2015-02-11 2:12 ` Peter Maydell
2015-02-11 12:33 ` Michael S. Tsirkin
2015-02-11 13:29 ` Peter Maydell
2015-02-11 14:09 ` Michael S. Tsirkin
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=20150211122818.GB4623@redhat.com \
--to=mst@redhat.com \
--cc=agraf@suse.de \
--cc=cornelia.huck@de.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--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.