On 5 November 2015 at 14:58, Gerd Hoffmann <kra...@redhat.com> wrote: > On Do, 2015-11-05 at 14:45 +0000, Peter Maydell wrote: >> On 5 November 2015 at 14:42, Gerd Hoffmann <kra...@redhat.com> wrote: >> > Chicken & egg issue in that case because airlied (linux kernel drm >> > maintainer) asked to have the qemu changes merged before taking the >> > virtio-gpu pull request. So I had no other chance than creating the >> > patches with not-yet upstream virtio header changes ... >> >> Hmm. If I'd realised that at the time I'd have pushed back on it. >> We should never take code that relies on upstream kernel >> ABI that hasn't been accepted by the maintainer yet. > > The reason airlied asked for qemu being upstream first is to avoid > having code in the kernel tree not accepted by qemu yet ... > > So, one of the two has to go first ;)
Right, but this isn't a symmetrical arrangement. If on the kernel side the ABI is changed before it's finally accepted into mainline, that means that any QEMU that got released with changes made on the basis of not-yet-upstream kernel patches will be broken. But if the kernel accepts code which needs a not-yet-in-qemu feature to be useful, that doesn't break the kernel, because the kernel isn't actually dependent on the QEMU changes. That's why I think the kernel side of the ABI always needs to go first (the kernel provides the ABI, QEMU uses it, never the other way around). thanks -- PMM
