linux-kernel - Re: [GIT PULL] More Kbuild updates for v5.4-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHk-=wjhKeCH+yGOmHk_2v8GY2EHwXboSS6R-Jov63JHat21XQ@mail.gmail.com>
Date:   Sun, 29 Sep 2019 09:59:54 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        masahiroy@...nel.org
Subject: Re: [GIT PULL] More Kbuild updates for v5.4-rc1

On Sat, Sep 28, 2019 at 9:00 PM Masahiro Yamada
<yamada.masahiro@...ionext.com> wrote:
>
> The concept of header test is to make sure every header
> is self-contained,

Yes, I realize. But at the same time the filenames it creates are very
annoying and clutter up the tree, and I'm not sure we really want that
in the first place.

The thing _I_ would want is actually a lot less includes, and a lot
more streamlined, just for better build times. I sometimes get a small
pull, and wonder why the *whole* tree recompiles, and realize that
it's due to some really obscure header file that just gets included
"in case".

So I'd like us to be stricter about header files another way entirely,
and I'm not sure that header files should need to be completely
independent.

> Of course, you can argue that it is addressing hypothetical issues
> "what if the include directives are arranged in this order?",
> that nobody has been hit before.

Well, I think people hit it all the time but just add the right header
file when some build fails.

In a perfect world, we'd have something that understands what symbols
get declared in each header file, and what symbols each header file
needs, and have a SAT solver for this that actually also understands
about different configurations and architectures. And actually
minimize the headers, and have a tool that warns when you have
unnecessary ones - or are lacking some.

Yeah, it's probably too complex to be worth the pain, but it would be lovely.

> But, at least, I want to continue compile-testing
> uapi headers that are exported to user-space.

I think the uapi headers have a much stronger case for being
self-sufficient, but even there I'd really prefer some other model
than "*.h.s".

We have the dot-files for dependencies and for tracking the command
that was used to generate them, I'd much rather have that. At least
then we wouldn't uglify the directory structure.

Yea, I realize that some people "solve" that problem by just not
building in the source-tree at all, but I find that annoying too.

               Linus