Em Tue, Aug 23, 2016 at 10:28:39PM -0400, Kees Cook escreveu:

On Tue, Aug 23, 2016 at 10:30 AM, Arnaldo Carvalho de Melo
[off-list ref] wrote:

quoted

Em Mon, Aug 22, 2016 at 05:28:42PM -0700, H. Peter Anvin escreveu:

quoted

On August 22, 2016 5:07:39 PM PDT, "Luis R. Rodriguez" [off-list ref] wrote:

quoted

On Fri, Aug 19, 2016 at 03:31:47PM -0700, Kees Cook wrote:

quoted

quoted

quoted

quoted

Aren't a bunch of these files exact duplicates of the headers in

include/linux?

quoted

quoted

quoted

Indeed... This a userspace tools/ architecture decision that was made
long ago, so its not up to me, I am just following the strategy
devised and picked up.  Refer to
7d7d1bf1d1dabe435ef50efb051724b8664749cb ("perf bench: Copy kernel
files needed to build mem{cpy,set} x86_64 benchmarks") for an example
of previous similar work. By sharing header files this enable more
tools/ to be hacked on.

quoted

quoted

I think this is a legacy from before the uapi change that should
really be fixed.  If we need to export additional kernel structures
for the tools, we could define a third level of we really need it.

quoted

No, it is something recent, its just that from time to time files that
tools/ included from outside, i.e. from the kernel sources, made tools/
break, so after discussion with Linus and Ingo[1], it was decided we would

This [1] reference seems missing. I'm curious to see the thread. I

I added the '[1]', went to look for the discussion yesterday, but it was
a private conversation with ~15 people, bummer, but the one below has
Ingo describing it in another occasion where a new utility got added to
tools/, objtool:

  https://lkml.kernel.org/r/20160309183945.GA17956@gmail.com

And yeah, I started using stuff directly from the kernel, breakage took
place, we changed course.

wonder if something could be done to just generate the needed headers
from the canonical locations into the tools/ locations?

Then that would bring possible problems, better to do it manually when
auto-detected.
 

quoted

grab copies and never more access anything outside tools/ directly.

Instead we would check for changes and warn the tools/ developers about
it, so that they could check what has changed, that could mean changes
should/could be done to tools/ using those headers.

Is there anything automated in place to notice when these changes happen?

See 791cceb89f7987c0375ff2e8971928a47f62ccae, among others, but it will
amount to something like:

    Changes detected by the tools build system:
    
      $ make -C tools/perf O=/tmp/build/perf install-bin
      make: Entering directory '/home/acme/git/linux/tools/perf'
        BUILD:   Doing 'make -j4' parallel build
--->  Warning: tools/include/uapi/linux/bpf.h differs from kernel <-------
        INSTALL  GTK UI
        CC       /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o
      <SNIP>
      $

- Arnaldo