From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751225AbdAaSAk (ORCPT ); Tue, 31 Jan 2017 13:00:40 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:32955 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751117AbdAaSAa (ORCPT ); Tue, 31 Jan 2017 13:00:30 -0500 Date: Tue, 31 Jan 2017 19:00:25 +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: <20170131180025.GA2980@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> <20170130075832.GA9241@gmail.com> <20170131054124.GA21189@ravnborg.org> <20170131163508.GA16162@gmail.com> <20170131172259.GA22807@ravnborg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170131172259.GA22807@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: > > > > > > So just to repeat - it is an error prone design to let users > > > of the kernel uapi maintain their own copies of the kernel > > > uapi header. It is the job of the kernel. > > > > But "random copies" is not what perf does. Tell me, how is the perf mechanism of > > using the headers "error-prone"? It's a delayed COW mechanism - COW is not an > > error-prone concept in any way ... > > The whole concept that user space have the burden to maintain a set of headers > describing the uapi provided by the kernel is the point of discussion. That's your characterisation and I think it's misleading: they don't have to "maintain a set of headers", they can, if they'd like to: "maintain a _copy_ of a small number of headers that the typical user-space tooling project is interested in" which is different from how you framed it. > The randomness come into play when a user space developer are faced with the > challenge that the programm require access to something described by the kernel > uapi and then have to hunt for a header that describes said uapi. > > In this thread we have covered one rational reason to push thus > burden to user space - to give the kernel the freedom to repair > past stupidity (being that in naming or some other sort). There's no real "burden" for heaven's sake: it's having to execute a 'cp' every now and then and check whether the result still builds (it will build just fine in the overwhelming majority of cases). > So lets turn around the arguments - and from a user space > perspective what is the benefit of maintaining a set of headers > describing the kernel uapi? Firsty, the headers are not maintained by the user-space project, 99.999% of the maintenance is done by the kernel developers. > Obviously this allows user space to name thing exactly the way they like, and > allows user space to put all sorts of strange things in the header files > describing the kernel uapi. Huh? Again, my suggestion is to to _copy_ the kernel header the tooling project is interested in as-is, and this is exactly what perf does. We don't change the UAPI headers, we copy them verbatim and check during the build that the copy is exact. > Are there other benefits that is missed which makes the > concept of letting user space maintain header files describing > the kernel uapi a good idea that is missed? Yes, you missed a lot of the benefits. Firstly, the user-space tooling project that relies on some UAPI header with Linux kernel ABI details in it, if it so wishes, maintains a _copy_ of the affected headers, which is vastly less work and 'burden' than 'maintaining headers'. Secondly, doing this copy has numerous advantages over using the UAPI headers from the distro installation: - Additions to the ABI are monitored by the tooling project. Say there's external tooling that relies on the perf system call, and uses a copy of perf_events.h. It can see new ABI additions in new versions of the file, and can add support for them. If on the other hand the file is just shared with whatever distro kernel headers there are on the system, there's no information about ABI progress. Advantage: changes to the ABI can be seen in the tool's Git repository, the "git log" of the header shows how the versions got updated and how the tool adopted to new ABI additions. - The tooling project is more self-contained: it can build just fine in more limited environments that don't have the kernel headers installed. Advantage: more robust tool build process, fewer dependencies. - So the tooling project can copy the kernel header _before_ the updated kernel header trickles through to distros. This has the advantage of being able to add tooling support for new ABI additions before it all goes into the 'official' UAPI headers a distro includes, and speeds up ABI propagation. Advantage: faster ABI propagation to tooling. - In fact this model allows the tooling project to host new kernel ABI additions in its development process, so sometimes it has the new UAPI header _before_ the upstream kernel has it. (Obviously the upstream kernel has to pull it for it to become the official UAPI header, so this only works for subsystems where there's good communication between the tooling developers and the kernel developers.) This is what tools/perf does quite often. Advantage: better development model where tooling can develop new kernel features hand in hand with kernel developers. I.e. most of the advantages of the copied headers are for the _tooling project_, not for the kernel. Your one sided characterization of the copying method as a 'burden' ignores all that. Thanks, Ingo