Re: [PATCH 5/8] standard-headers: Add virtio_video.h

[Peter Griffin]

Hi Peter,

On Fri, 10 Dec 2021, Peter Maydell wrote:

> On Thu, 9 Dec 2021 at 15:03, Peter Griffin <peter.griffin@linaro.org> wrote:
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> >  include/standard-headers/linux/virtio_video.h | 483 ++++++++++++++++++
> >  1 file changed, 483 insertions(+)
> >  create mode 100644 include/standard-headers/linux/virtio_video.h
> 
> As MST notes, content in include/standard-headers/ is from
> upstream Linux, and it gets into QEMU by:
> 
>  (1) getting it into the Linux kernel tree
>  (2) changing QEMU's scripts/update-linux-headers.sh to know that
>      it wants this new header file
>  (3) running the script to create a patch which updates the headers
>      to match a new enough mainline Linux kernel that has the file
> 
> This is important because files in standard-headers are used
> by QEMU on all host OSes, not just Linux. Things like:
> 
> > +#include <linux/virtio_config.h>
> 
> or
> 
> > +       __le32 version;
> 
> won't compile on BSD. The update-linux-headers.sh script takes
> care of sanitizing this kind of Linuxism when it copies the
> header into the QEMU tree.
> 
> The process also ensures that we don't accidentally bring in
> support for a kernel feature until its userspace ABI is finalized.
>
> Where a new feature is being worked on on both the kernel and the
> QEMU side of things, you can post QEMU RFC patchsets which
> temporarily have ad-hoc header file updates (eg created from
> a kernel tree that has the not-yet-upstream kernel patches), but
> these should be clearly marked as RFCs and we don't take the
> QEMU patches until the kernel side is upstream and the QEMU
> headers can be cleanly generated from a mainline kernel commit.

Thanks for the review and the explanation :) I meant to call out this
header file inclusion in the cover letter as I was not sure of the
process on that.

This series should have been marked RFC then as the kernel side is
not merged yet. The purpose of this series is to hopefully unblock
getting the kernel side merged though, as lack of Qemu support and
a test setup that supported vicodec were both mentioned last time
in the review process.

Thanks,

Peter.