Hi On Thu, Dec 21, 2023 at 10:55 AM Akihiko Odaki <akihiko.od...@daynix.com> wrote: > > On 2023/12/19 23:14, Peter Maydell wrote: > > On Tue, 19 Dec 2023 at 13:49, Huang Rui <ray.hu...@amd.com> 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.hu...@amd.com> > >>>> --- > >>>> > >>>> 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-3b97d95f7...@collabora.com/ > >>>> 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
