From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuNyU-0001GZ-MT for qemu-devel@nongnu.org; Thu, 05 Nov 2015 12:05:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZuNyP-0000WC-Np for qemu-devel@nongnu.org; Thu, 05 Nov 2015 12:05:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZuNyP-0000W4-Ib for qemu-devel@nongnu.org; Thu, 05 Nov 2015 12:05:17 -0500 References: <1446725610.30393.23.camel@redhat.com> <563B5E37.2040701@redhat.com> <8737wk1m0p.fsf@linaro.org> From: Laszlo Ersek Message-ID: <563B8C4A.70307@redhat.com> Date: Thu, 5 Nov 2015 18:05:14 +0100 MIME-Version: 1.0 In-Reply-To: <8737wk1m0p.fsf@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] virtio-gpu doesn't build if you do a linux-headers update from kvm/next List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= Cc: Peter Maydell , Paolo Bonzini , QEMU Developers , Gerd Hoffmann On 11/05/15 16:52, Alex Benn=C3=A9e wrote: >=20 > Laszlo Ersek writes: >=20 >> On 11/05/15 13:32, Peter Maydell wrote: >>> On 5 November 2015 at 12:13, Gerd Hoffmann 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 head= ers >>>> 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 proje= ct >> 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. >=20 > 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 (=3D 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.