From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751542AbdAaQo5 (ORCPT ); Tue, 31 Jan 2017 11:44:57 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:32956 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849AbdAaQoo (ORCPT ); Tue, 31 Jan 2017 11:44:44 -0500 Date: Tue, 31 Jan 2017 17:35:08 +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: <20170131163508.GA16162@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170131054124.GA21189@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: > Obvious when there are two vastly different solutions there are some > middle ground solutions too. > > And perf implements a tool based method to check that the manually > copied/created/maintained headers are in sync with the kernel. which is just > another way to maintain a set of copied headers. > > But this does not at all address the point which is that it is an unessesary > burden to put on all the _users_ of the kernel uapi headers to amintain their > own copy of the kernel headers (tool assisted or not). In 99% of the cases it's trivial to keep them updated on the tooling side. Basically a copy only has to be made if a change is done - and changes are not that common in the ABI space. > The rationale behind requesting the users of the kernel uapi headers seems to be > that the kernel people would like to have the freedom to fix wrong doings in the > past without violatign the uapi. > > So the benefit here is simpler headers on the kernel side compared > to all users of kernel uapi heders to manually (tool assisted or not) > maintaining their own copies of the uapi kernel headers. I was reacting to this original claim of yours: > > > 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. There's no 'random copies' - they are copies of past, valid versions of the kernel headers, and there's a mechanism to update them to the latest. > Heck - if this is how it should be done then the the kernel > should provide the copy of the headers that describe the > uapi and the kernel should have the tool infrastructure to check > that the headers are OK. > Not all the users outside the kernelspace. > > 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 ... Thanks, Ingo