linux-kernel - Re: [PATCH V2] x86: Allow built-in command line to work in early kernel init

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]

Date:	Tue, 12 May 2015 10:39:33 -0700
From:	Matthew Garrett <matthew.garrett@...eos.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>, x86@...nel.org,
	hpa@...or.com, mingo@...hat.com, tglx@...utronix.de,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg59@...eos.com>
Subject: Re: [PATCH V2] x86: Allow built-in command line to work in early
 kernel init

On Tue, May 12, 2015 at 2:28 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Matthew Garrett <matthew.garrett@...eos.com> wrote:
>
>> Any feedback on this?
>
> So I worry about:
>
>  - the fragmented nature of it: lots of non-obvious pieces of code
>    will now be scattered all around arch/x86/.

We've got four different entry points and they all work under very
different constraints - I can't see any real way to share this code.
We could move all the command line handling code into a single file
and #include it with different ifdefs, but I'm not sure that that's
less confusing?

>  - the crazy #ifdefs scattered around

The #ifdefs could be abstracted behind a couple of simple helper functions?

>  - the various pieces of data scattered around

We're trying to use the same data in what are pretty much four
logically distinct codebases. I'm not sure that there's any way around
that other than linker magic, and that seems like it'd make things
even more non-obvious.

> ... so while I don't mind the feature in principle, but it should be
> centralized much better IMHO, made Kconfig invariant at least in its
> fragmented callbacks, with only the very strictly boot method specific
> details spelled out explicitly.
>
> I have not thought much about how to achieve that :-/

I'm happy to reimplement this, but outside losing the #ifdefs I'm
struggling to see any real way of improving it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/