linux-kernel - Re: [PATCH 6/8] CMDLINE: x86: convert to generic builtin command line

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: <dde17d82-3e56-4b9f-8b6d-dae3d523d44e@intel.com>
Date: Thu, 2 Oct 2025 16:10:44 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Daniel Gimpelevich <daniel@...pelevich.san-francisco.ca.us>
Cc: "Daniel Walker (danielwa)" <danielwa@...co.com>,
 Will Deacon <will@...nel.org>, Christophe Leroy
 <christophe.leroy@...roup.eu>, Rob Herring <robh@...nel.org>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Pratyush Brahma <quic_pbrahma@...cinc.com>,
 Tomas Mudrunka <tomas.mudrunka@...il.com>,
 Sean Anderson <sean.anderson@...o.com>, "x86@...nel.org" <x86@...nel.org>,
 "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
 "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin" <hpa@...or.com>,
 "xe-linux-external(mailer list)" <xe-linux-external@...co.com>,
 Ruslan Ruslichenko <rruslich@...co.com>,
 Ruslan Bilovol <ruslan.bilovol@...il.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 6/8] CMDLINE: x86: convert to generic builtin command line

On 10/2/25 15:38, Daniel Gimpelevich wrote:
> On Thu, 2025-10-02 at 14:55 -0700, Dave Hansen wrote:
>> That's not a bad idea. Or, even if you can pick two amenable
>> architectures to start with it will make it really obvious that this is
>> useful. Two architectures means a *lot*, IMNHO. Two is a billion times
>> better than one.
> I think it's a bad idea, if I understand it correctly. The patchset
> conceptually patches a mechanism of the kernel as a whole, but one which
> just so happens to need to be implemented separately for each arch.
> Breaking it down like you suggest creates an embarrassingly high
> likelihood of different architectures' implementations of it going out
> of sync, a previous situation that this patchset was partly intended to
> address. I say keep it atomic. If it breaks on an arch or two but not
> others and nobody notices right away, that would be better addressed
> with a new patch when someone eventually does notice. Just my 2¢…

How is the approach to "keep it atomic" working out so far? ;)

The kernel isn't exactly developed in secret. It's also not hard at all
to, say, once a week to peek at linux-next and do a lore search (or use
lei) if anyone is desperately worried about the ~50 lines per
architecture going out of sync.