On 11/05/15 16:52, Alex Bennée wrote: > > Laszlo Ersek <ler...@redhat.com> writes: > >> On 11/05/15 13:32, Peter Maydell wrote: >>> On 5 November 2015 at 12:13, Gerd Hoffmann <kra...@redhat.com> wrote: >>>>> etc, because all the virtio_gpu definitions disappear from >>>>> include/standard-headers/linux/virtio_gpu.h. >>>> >>>> Updates not yet in mainline, they are sitting in drm-next and should >>>> land during the merge window (i.e. 4.4-rc1 should have them). >>>> >>>> I'd suggest to exclude virtio_gpu.h changes when updating linux headers >>>> for the time being. >>> >>> I would strongly prefer it if we could get to a point where >>> we can say "kernel headers must only be updated from this tree" >>> and be guaranteed that it always works. This used to be true >>> with the tree in question being kvm/next, but it doesn't seem >>> to be so now. If it's going to be common that we have header >>> changes that don't go via kvm/next, maybe we need to coordinate >>> a tree that merges together the abi-guaranteed-stable changes >>> from different places before they hit mainline? >> >> I've always frowned upon importing headers from one project to another >> project. First, they can have different coding styles. (Case in point.) >> Second, not everything that needs to be defined for the original project >> is useful to the receiving project, and I find such cruft in the >> receiving project very annoying. Third, in some cases it might even >> raise licensing questions. >> >> If it is an ABI, it should be specified in text format somewhere, and >> then the projects can have their independent type definitions, macros >> etc that implement the spec. > > Surely the kernel uapi includes is that textual format. Once stuff is > accepted into the master kernel tree there is your stable API.
What is uapi for? If it is for QEMU (the userspace process) to consume the host kernel's services, then I agree. If uapi is for the guest kernel to consume (= drive) QEMU's virtual hardware, then I strongly disagree. In that case Linux is just one of the possible guests that can drive that hardware. (Side point: and QEMU is just one of the emulators / hypervisors that can provide that hardware. Which is why the actual hardware description should exist independently of both.) I'll elaborate elsewhere in the thread. Thanks Laszlo > FWIW the few bits I've done that involve syncing headers I basically > carry a [DEV] patch in my QEMU tree until the feature is finally merged > in the kernel and then I do my final re-base against the official tree > state.
