Re: [PATCH v6 01/11] linux-headers: Update to kernel headers to add venus capset

[Marc-André Lureau <marcandre.lureau@xxxxxxxxx>]

Hi

On Thu, Dec 21, 2023 at 10:55 AM Akihiko Odaki <akihiko.odaki@xxxxxxxxxx> wrote:
>
> On 2023/12/19 23:14, Peter Maydell wrote:
> > On Tue, 19 Dec 2023 at 13:49, Huang Rui <ray.huang@xxxxxxx> wrote:
> >>
> >> On Tue, Dec 19, 2023 at 08:20:22PM +0800, Akihiko Odaki wrote:
> >>> On 2023/12/19 16:53, Huang Rui wrote:
> >>>> Sync up kernel headers to update venus macro till they are merged into
> >>>> mainline.
> >>>
> >>> Thanks for sorting things out with the kernel and spec.
> >>>
> >>>>
> >>>> Signed-off-by: Huang Rui <ray.huang@xxxxxxx>
> >>>> ---
> >>>>
> >>>> Changes in v6:
> >>>> - Venus capset is applied in kernel, so update it in qemu for future use.
> >>>>
> >>>> https://lore.kernel.org/lkml/b79dcf75-c9e8-490e-644f-3b97d95f7397@xxxxxxxxxxxxx/
> >>>> https://cgit.freedesktop.org/drm-misc/commit/?id=216d86b9a430f3280e5b631c51e6fd1a7774cfa0
> >>> Please include the link to the upstream commit in the commit message.
> >>
> >> So far, it's in drm maintainers' branch not in kernel mainline yet. Do I
> >> need to wait it to be merged into kernel mainline?
> >
> > For an RFC patchset, no. For patches to be merged into QEMU
> > the headers change must be in the kernel mainline, and the
> > QEMU commit that updates our copy of the headers must be a
> > full-sync done with scripts/update-linux-headers.sh, not a
> > manual edit.
>
> Apparently the kernel change is unlikely to be merged to mainline before
> QEMU 9.0 so we need to come up with some idea to deal with this.
>
> The release of Linux 6.7 is near and the development of 6.8 will start
> soon. So it was nice if the change made into 6.8, but unfortunately it
> missed the *probably last* drm-misc tree pull request for 6.8:
> https://lore.kernel.org/all/aqpn5miejmkks7pbcfex7b6u63uwsruywxsnr3x5ljs45qatin@nbkkej2elk46/
>
> It will still get into linux-next so we may retrieve headers from
> linux-next. Or we may add the definition to
> hw/display/virtio-gpu-virgl.c; the duplicate definition warning will
> tell when the definition becomes no longer necessary. I'm fine with
> either option.

The second option seems better to me, as it can avoid pulling unwanted changes.

thanks

-- 
Marc-André Lureau