From: Ingo Molnar <mingo@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Thomas Gleixner <tglx@linutronix.de>, x86-ml <x86@kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] x86/boot: Get rid of linux/init.h include
Date: Mon, 25 Nov 2024 09:24:28 +0100 [thread overview]
Message-ID: <Z0Q0PJzTMg_Or22I@gmail.com> (raw)
In-Reply-To: <20241122170227.GAZ0C5I-F8AUpwCAcG@fat_crate.local>
* Borislav Petkov <bp@alien8.de> wrote:
> On Fri, Nov 22, 2024 at 05:55:52PM +0100, Ingo Molnar wrote:
> > > --- a/arch/x86/boot/compressed/head_32.S
> > > +++ b/arch/x86/boot/compressed/head_32.S
> > > @@ -24,7 +24,6 @@
> > > */
> > > .text
> > >
> > > -#include <linux/init.h>
> > > #include <linux/linkage.h>
> > > #include <asm/segment.h>
> > > #include <asm/page_types.h>
> > > @@ -32,6 +31,10 @@
> > > #include <asm/asm-offsets.h>
> > > #include <asm/bootparam.h>
> > >
> > > +#ifdef KERNEL_PROPER_HEADER
> > > +#error Do not include kernel proper namespace headers
> > > +#endif
> >
> > The canonical solution in such cases is to use the existing header
> > guard, ie:
> >
> > #ifdef _LINUX_INIT_H
> > # error Do not include kernel proper namespace headers
> > #endif
> >
> > Then we can skip defining KERNEL_PROPER_HEADER as well, and this change
> > will be purely to x86 code.
>
> Yap, I know, thought about it.
>
> However, if we have to protect against every header, then we will have to do
> a big
>
> if defined...
>
> which doesn't really work.
>
> For the above example:
>
> #if defined(_LINUX_INIT_H) || defined(_LINUX_LINKAGE_H)
>
> and that would protect against the two headers which are included here.
>
> If someone includes another one, it won't fire.
And if someone doesn't add the ugly KERNEL_PROPER_HEADER defines to a
new header that somehow gets included into the decompressor build
virally, it won't fire either. I think it's better to concentrate the
uglies in the 'weird' code, ie. the decompressor.
Also, what's the root problem being solved? The changelog says:
> no collisions and ugly ifdeffery when those kernel proper headers
> get shared.
But that's pretty vague - is there some recent build regression this is
responding to? Which kernel headers collided with which headers used by
the decompressor build?
Thanks,
Ingo
next prev parent reply other threads:[~2024-11-25 8:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-22 16:31 [RFC PATCH] x86/boot: Get rid of linux/init.h include Borislav Petkov (AMD)
2024-11-22 16:55 ` Ingo Molnar
2024-11-22 17:02 ` Borislav Petkov
2024-11-25 8:24 ` Ingo Molnar [this message]
2024-11-25 10:22 ` Borislav Petkov
2024-11-25 16:57 ` Brian Gerst
2024-11-25 17:09 ` Borislav Petkov
2024-11-25 17:31 ` Brian Gerst
2024-11-25 18:15 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z0Q0PJzTMg_Or22I@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.