Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 23 Mar 2020 11:19:21 -0700
User-Agent: K-9 Mail for Android
In-Reply-To: <CACdnJusmAHJYauKvHEXNZKaUWPqZoabB_pSn5WokSy_gOnRtTw@mail.gmail.com>
References: <CAP6exY+LnUXaOVRZUXmi2wajCPZoJVMFFAwbCzN3YywWyhi8ZA@mail.gmail.com> <D31718CF-1755-4846-8043-6E62D57E4937@zytor.com> <CAP6exYJHgqsNq84DCjgNP=nOjp1Aud9J5JAiEZMXe=+dtm-QGA@mail.gmail.com> <8E80838A-7A3F-4600-AF58-923EDA3DE91D@zytor.com> <CACdnJusmAHJYauKvHEXNZKaUWPqZoabB_pSn5WokSy_gOnRtTw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH 1/1] x86 support for the initrd= command line option
To:     Matthew Garrett <mjg59@google.com>
CC:     ron minnich <rminnich@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "maintainer:X86 ARCHITECTURE..." <x86@kernel.org>,
        lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>
From:   hpa@zytor.com
Message-ID: <A814A71D-0450-4724-885B-859BCD2B7CBD@zytor.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On March 20, 2020 11:19:19 AM PDT, Matthew Garrett <mjg59@google=2Ecom> wro=
te:
>On Thu, Mar 19, 2020 at 5:59 PM <hpa@zytor=2Ecom> wrote:
>
>> It has been designated consumed by the bootloader on x86 since at
>least 1995=2E So ARM broke it=2E
>
>Eh=2E This feels like a matter of semantics - booting the kernel via EFI
>results in it being parsed by the boot stub, so in that case we're
>left arguing that the boot stub isn't the kernel=2E I can just about buy
>that, but it's a stretch=2E For this change to actually break something,
>we'd need the bootloader to be passing something that the kernel
>parses, but not actually populating the initrd fields in bootparams=2E
>That seems unlikely?

You are right as long as this is the very last priority *and* neither boot=
 loaders nor the kernel will croak on unexpected input (I really object to =
Ron calling the non-x86 version "standard", but that's a whole other ball o=
f wax=2E)

Pointing to any number of memory chunks via setup_data works and doesn't n=
eed to be exposed to the user, but I guess the above is reasonable=2E

*However*, I would also suggest adding "initrdmem=3D" across architectures=
 that doesn't have the ambiguity=2E
--=20
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E