From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752564AbdA3H6s (ORCPT ); Mon, 30 Jan 2017 02:58:48 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:34597 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752539AbdA3H6r (ORCPT ); Mon, 30 Jan 2017 02:58:47 -0500 Date: Mon, 30 Jan 2017 08:58:33 +0100 From: Ingo Molnar To: Sam Ravnborg Cc: linux-kernel@vger.kernel.org, Andrew Morton , Andy Lutomirski , Borislav Petkov , "H . Peter Anvin" , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , Yinghai Lu , Arnaldo Carvalho de Melo Subject: Re: [PATCH 01/50] x86/boot/e820: Introduce arch/x86/include/asm/e820/types.h Message-ID: <20170130075832.GA9241@gmail.com> References: <1485641531-22124-1-git-send-email-mingo@kernel.org> <1485641531-22124-2-git-send-email-mingo@kernel.org> <20170129171336.GA4752@ravnborg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170129171336.GA4752@ravnborg.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Sam Ravnborg wrote: > On Sat, Jan 28, 2017 at 11:11:22PM +0100, Ingo Molnar wrote: > > > > The plan is to keep the old UAPI header in place but the kernel won't > > use it anymore - and after some time we'll try to remove it. (User-space > > tools better have local copies of headers anyway, instead of relying > > on kernel headers.) > > The idea with uapi is the the kernel provides a sane set of headers > to be used by user space. > So we avoid random copies that is maintained by random people in random > ways resulting in random bugs. Your argument is simplistic which presents a false dichotomy: maintaining a copy or fully sharing the header are not the only two options available to share the information in the headers between the kernel and tooling: for example perf uses a half-automated method where headers are copied from the kernel, but also checked automatically against the upstream kernel, and a (non-fatal) warning is emitted during the build if the upstream header has changed. For example today the perf build shows these UAPI header warnings: Warning: arch/powerpc/include/uapi/asm/kvm.h differs from kernel Warning: arch/arm/include/uapi/asm/kvm.h differs from kernel ... because new bits were added to those two UAPI headers. For example the new ARM bits were: triton:~/tip/tools/perf> diff -up ../arch/arm/include/uapi/asm/kvm.h ../../arch/arm/include/uapi/asm/kvm.h --- ../arch/arm/include/uapi/asm/kvm.h 2017-01-23 10:10:18.846003002 +0100 +++ ../../arch/arm/include/uapi/asm/kvm.h 2017-01-28 09:35:12.383587930 +0100 @@ -84,6 +84,15 @@ struct kvm_regs { #define KVM_VGIC_V2_DIST_SIZE 0x1000 #define KVM_VGIC_V2_CPU_SIZE 0x2000 +/* Supported VGICv3 address types */ +#define KVM_VGIC_V3_ADDR_TYPE_DIST 2 +#define KVM_VGIC_V3_ADDR_TYPE_REDIST 3 +#define KVM_VGIC_ITS_ADDR_TYPE 4 + +#define KVM_VGIC_V3_DIST_SIZE SZ_64K +#define KVM_VGIC_V3_REDIST_SIZE (2 * SZ_64K) +#define KVM_VGIC_V3_ITS_SIZE (2 * SZ_64K) + #define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */ #define KVM_ARM_VCPU_PSCI_0_2 1 /* CPU uses PSCI v0.2 */ ... so for these changes the perf side copy can be updated safely. Had the changes been more intricate, the changes can be copied too - while adopting the tooling source code as well. See the tools/perf/check-headers.sh script. This IMHO is a far more intelligent and far more robust approach than blind sharing or detached copies, because it: - forces new changes from upstream to be considered and adapted by tooling - header (and thus ABI) synchronization is guaranteed (eventually) - it does not actually couple the two source code bases in a rigid fashion: - the upstream kernel is free to change those headers (at least from perf's POV) in any sane way, those changes can be adapted. - every step is conscious and there's no way to accidentally break tooling via header changes - nor does tooling hinder the kernel from progressing its source code base. It's basically a script based COW filesystem with guaranteed propagation and guaranteed synchronization. > The step(s) outlined here can only result in inconsistency and > cannot benefit neither user space nor the kernel in the long run. That's simply not true, see above. > The uapi shall be lean and clean headers, and shall include > no info whatsoever that is not relevant for user space. I agree with that characterization, and that will be even more so with my changes: my series makes uapi/asm/bootparam.h more self-contained, more lean - while still defining the full ABI. > But requiring all user space programs (diverse libc variants, > other programs) to maintain their own copy can only result in > inconsistencies that is the benefit for no one. That's simply not true, see above. Note that my changes try to keep the 'UAPI promise' (in that the old e820.h header is still around), while still modifying the kernel side. What _IS_ insane is to somehow construe the UAPI headers as a rigid construct that forces the kernel source to keep using poorly chosen names like 'struct e820entry' forever... Thanks, Ingo