Re: [PATCH 10/11] x86/xip: resolve alternative instructions at build

[Borislav Petkov <bp@alien8.de>]

On Mon, Mar 23, 2015 at 12:46:39AM -0700, Jim Kukunas wrote:
> Since the .text section can't be updated at run-time, remove the
> .alternatives sections and update the .text at build time. To pick the
> proper instructions, Kconfig options are exposed for each X86_FEATURE
> that needed to be resolved. Each X86_FEATURE gets a corresponding
> CONFIG_XIP_ENABLE_X86_FEATURE_ option. Based on whether this option
> is set, a resolver macro is setup to either generate that instruction,
> or the fallback. The resolver needs to be defined for each FEATURE, and
> the proper one is chosen via preprocessor string pasting.
> 
> This approach is horrific and ugly.

You said it.

And with XIP enabled - whatever that means, your announce message could
explain a lot more and more verbosely what this whole patchset is all
about - this kernel is not going to be generic anymore but it will be
destined only for the machine it is being built for, correct?

If that is so, how are distros supposed to ship one kernel with XIP or
is this some obscure feature distros won't have to enable anyway?

Concerning this particular patch, I'd suggest a switch which simply
disables alternatives patching at run time so that you don't add this
ifdeffery to alternative.c

Btw, why do you even have to disable the alternatives? I see this in
your patch 1/11:

+         location in RAM. As a result, when the kernel is located in storage
+         that is addressable by the CPU, the kernel text and read-only data
+         segments are never loaded into memory, thereby using less RAM.

is this it? To save some memory? Probably embedded, maybe some light
bulb running linux... Yuck.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--