From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751585AbdAaFsw (ORCPT ); Tue, 31 Jan 2017 00:48:52 -0500 Received: from asavdk3.altibox.net ([109.247.116.14]:48315 "EHLO asavdk3.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751423AbdAaFsO (ORCPT ); Tue, 31 Jan 2017 00:48:14 -0500 Date: Tue, 31 Jan 2017 06:41:24 +0100 From: Sam Ravnborg To: Ingo Molnar 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: <20170131054124.GA21189@ravnborg.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170130075832.GA9241@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.2 cv=WJY9ZTkR c=1 sm=1 tr=0 a=Ij76tQDYWdb01v2+RnYW5w==:117 a=Ij76tQDYWdb01v2+RnYW5w==:17 a=kj9zAlcOel0A:10 a=7gkXJVJtAAAA:8 a=pOLkWC4paGT2zjQyPpEA:9 a=yUmEGQon_fsufj1G:21 a=jkUuKxTBgk08p_EA:21 a=CjuIK1q_8ugA:10 a=E9Po1WZjFZOl8hwRPBS3:22 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 30, 2017 at 08:58:33AM +0100, Ingo Molnar wrote: > > * 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. 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). 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. 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. Sam