linux-kernel - Re: [broonie-misc:arm64-sysreg-gen 6/9] arch/arm64/include/asm/sysreg.h:125:10: fatal error: 'generated/asm/sysreg.h' file not found

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: <YjSoLTbVBZTNS0tL@sirena.org.uk>
Date:   Fri, 18 Mar 2022 15:41:33 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     kernel test robot <lkp@...el.com>, llvm@...ts.linux.dev,
        kbuild-all@...ts.01.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [broonie-misc:arm64-sysreg-gen 6/9]
 arch/arm64/include/asm/sysreg.h:125:10: fatal error:
 'generated/asm/sysreg.h' file not found

On Fri, Mar 18, 2022 at 02:15:07PM +0900, Masahiro Yamada wrote:
> On Thu, Mar 17, 2022 at 2:05 AM Mark Brown <broonie@...nel.org> wrote:

> > but that's only passed to CC (at least for bounds.s) via an
> > -I./arch/arm64/include/generated so won't be found with the generated/
> > prefix.  While this can be avoided by renaming the header and not
> > referencing it with the prefix I do see a bunch of other headers
> > throughout the tree being included with an explicit generated/ prefix so
> > I'm not sure this is what's supposed to be happening, it does seem like
> > a landmine somehow.

> Do not add 'generated/' prefix.

If that's something you don't want to support there's a bunch of
existing explicit usage of generated/ in include statements that need
fixing up.

> Let's think about this scenario.
> First foo.h was hard-coded, but sometime later,
> somebody noticed it is better to generate it by scripting.
> Why do we need to fix up #include <foo.h>  to #include <generated/foo.h>
> in all the call sites?
> Or do we need to have foo.h to wrap <generaged/foo.h> ?

I'm not sure I see a conflict from having both ways to reach the header
here and allowing people to do either as appropriate TBH, and indeed we
have other cases like uapi where we have both include/ and include/uapi
in the search path.

> No, users of foo.h do not need to know if it is
> a checked-in header of a generated one.

The use case I had was for partial conversion where some of the header
is pulled out into a generated file with the generated file wrapping
things.  The users are unaffected, and if the file is completely
converted to be generated would continue to be unaffected.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)