Re: [Qemu-devel] virtio-gpu doesn't build if you do a linux-headers update from kvm/next

[Laszlo Ersek]

On 11/05/15 16:52, Alex Bennée wrote:
> 
> Laszlo Ersek <address@hidden> writes:
> 
>> On 11/05/15 13:32, Peter Maydell wrote:
>>> On 5 November 2015 at 12:13, Gerd Hoffmann <address@hidden> 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.