On 11/05/15 16:11, Peter Maydell wrote: > 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).
I could be confused about what ABI means, but in case of *guest* kernel drivers (for virtual devices provided by QEMU), the dependency seems to be the opposite. Alex mentioned "kernel uapi includes" up-thread. To be honest, I don't know what "uapi" means here. Are those headers there to be relied upon by userspace processes that need services from the kernel? That would match your above argument. However, I found the following files there: include/uapi/linux/virtio_console.h include/uapi/linux/virtio_input.h include/uapi/linux/virtio_net.h include/uapi/linux/virtio_types.h include/uapi/linux/virtio_9p.h include/uapi/linux/virtio_balloon.h include/uapi/linux/virtio_scsi.h include/uapi/linux/virtio_rng.h include/uapi/linux/virtio_ids.h include/uapi/linux/virtio_ring.h include/uapi/linux/virtio_pci.h include/uapi/linux/virtio_gpu.h include/uapi/linux/virtio_config.h include/uapi/linux/virtio_blk.h Which kinda confuses me. I cannot imagine that a userspace process should depend on these, for the purpose of consuming kernel services. Instead, QEMU should *definitely* dictate in this case, because it provides the service (the hardware), and Linux has drivers that consume that service. Consider: there are virtio drivers in SeaBIOS, OVMF, and Windows too. Should QEMU include their header files as well? I think not. In other words, I agree with your argument, and the "QEMU depends on the kernel" statement, as far as QEMU plays the role of a userspace process that consumes the *host* kernel's services (VFIO, KVM, ...). However, when QEMU provides the *hardware* (which is hopefully described by an industry standard, or at least by some kind of independent documentation), then the *guest* kernel plays the consumer role (as do other non-Linux-kernel guests), and in that case the QEMU changes should go in first (hopefully after testing them with the under-development guest code, of course). Hence, I'm leaning to think that the above virtio header files should not be under uapi *at all*. They should be under "include/virtio", and should be private to the guest drivers. --*-- I think we had the same discussion when Wei was working on SMBIOS 3.0 for ARM. In <http://thread.gmane.org/gmane.comp.emulators.qemu/353282/focus=354806>, you asked "Is support for this all in the mainline kernel yet?" I didn't really understand that question -- it didn't matter. QEMU as a *platform* was learning how to provide a service that was governed by an industry standard. The status of *guest* kernel support (and of guest utility support) was irrelevant, in my opinion. Thanks Laszlo
