linux-kernel - Re: [GIT PULL v2] Kbuild updates for v5.15-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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210907144138.GG1583@gate.crashing.org>
Date:   Tue, 7 Sep 2021 09:41:38 -0500
From:   Segher Boessenkool <segher@...nel.crashing.org>
To:     Linus Torvalds <torvalds@...uxfoundation.org>
Cc:     Jakub Jelinek <jakub@...hat.com>,
        Florian Weimer <fweimer@...hat.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        llvm@...ts.linux.dev, linux-toolchains@...r.kernel.org
Subject: Re: [GIT PULL v2] Kbuild updates for v5.15-rc1

On Mon, Sep 06, 2021 at 02:24:39PM -0700, Linus Torvalds wrote:
> There are some *very* core header files that the kernel cannot include
> from outside. That "stdlib.h" thing already came up in the errors I
> quoted.
> 
> But I think you'll find that you guys want to include things like
> <errno.h> too, and you'll probably add others (<types.h>? things like
> that) simply because they always work fine in user space, and you'd
> not even notice.

Guess what.  We actually test this.  We do notice.  Except we don't,
because all those problems do not actually exist.

Long ago there were issues.  We do not live long ago now.

> I'm pretty sure you guys don't really want to deal with the pain that
> is crazy kernel people that have their very bare environment.

There are many other users that use freestanding environments.  Most of
them do use the standard headers.

> So you may *think* you want the kernel to use your header files
> "because compiler portability". Instead, you should be very thankful
> that we don't, and that you don't have to deal with our mess any more
> than you already do.

We would like it to be *less* pain, *less* unnecessary work, that is why
we would like the kernel to use the compiler headers.  Instead of what
the current patches do: getting rid of more of them, which will end up
as more work for everyone.


Segher