Date:   Tue, 31 Jan 2017 20:17:48 +0100
From:   Sam Ravnborg <sam@...nborg.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Lutomirski <luto@...capital.net>,
        Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Yinghai Lu <yinghai@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...radead.org>
Subject: Re: [PATCH 01/50] x86/boot/e820: Introduce
 arch/x86/include/asm/e820/types.h

Hi Ingo.

> >
> > 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).

We are obvious so far away in our perception of what is easy for
a user-space developers that is is not even funny.

> > 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.

In the inital mail triggering this plan was that the kernel
is moving away from having uapi headers what-so-ever.

Quoting the original mail:
"
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. 
"

Translated:
The plan is that the kernel will stop using headers from uapi/*
The headers will be left for a while and then they will be deleted.

The mail was centered about e820 - so maybe the outlined plan
was only for e820.
But I read it as a general pan - hence this mail thread.

So this is the plan that this argument is about.
No tooling will magically make files appear again.
And there is no benefit from user space that the kernel remove the files.

And the removing of files from uapi/ makes is hard for user space.
Because then a user-space developers have to find a definition
of the uapi somewhere else.

> 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.
Here the proposal was stop using the header in uapi/ and then later delete it.
So there i no file to copy - making the copying and tooling part irrelevant.

> 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'.

It is by no means a benefit to have a copy, rather than using the source.
There is a reason why we do not have multiple copies of the headers in the kernel
when we can avoid it. asm-generic is one way the kernel avoid the burden
of maintaining copies of headers.

All your remaining argumens zapped - I see the point of view.
But there are many other solutions for the same set of problems.

Perf being intimidate with the kernel is not the best example to come up with.
Think about to 100's of program that uses a few ioclt to talk with drivers etc.

	Sam

Powered by blists - more mailing lists