Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 22 Jun 2020 16:40:34 -0400
From:   Tom Rini <trini@konsulko.com>
To:     ron minnich <rminnich@gmail.com>
Cc:     lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Borislav Petkov <bp@suse.de>,
        Dominik Brodowski <linux@dominikbrodowski.net>,
        "H . Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] initrd: Remove erroneous comment
Message-ID: <20200622204034.GL27801@bill-the-cat>
References: <20200619143056.24538-1-trini@konsulko.com>
 <CAP6exYJ64Hy9y3Dzh9Asrq8Y0oDWYk+tf4UAcasEc-ZxTY8DAw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="ZGfVcqCQYT4RlWas"
Content-Disposition: inline
In-Reply-To: <CAP6exYJ64Hy9y3Dzh9Asrq8Y0oDWYk+tf4UAcasEc-ZxTY8DAw@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--ZGfVcqCQYT4RlWas
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 22, 2020 at 01:02:16PM -0700, ron minnich wrote:

> The other thing you ought to consider fixing:
> initrd is documented as follows:
>=20
>         initrd=3D         [BOOT] Specify the location of the initial ramd=
isk
>=20
> for bootloaders only.
>=20
> UEFI consumes initrd from the command line as well. As ARM servers
> increasingly use UEFI, there may be situations in which the initrd
> option doesn't make its way to the kernel? I don't know, UEFI is such
> a black box to me. But I've seen this "initrd consumption" happen.
>=20
> Based on docs, and the growing use of bootloaders that are happy to
> consume initrd=3D and not pass it to the kernel, you might be better off
> trying to move to the new command line option anyway.
>=20
> IOW, this comment may not be what people want to see, but ... it might
> also be right. Or possibly changed to:
>=20
> /*
>  * The initrd keyword is in use today on ARM, PowerPC, and MIPS.
>  * It is also reserved for use by bootloaders such as UEFI and may
>  * be consumed by them and not passed on to the kernel.
>  * The documentation also shows it as reserved for bootloaders.
>  * It is advised to move to the initrdmem=3D option whereever possible.
>  */

Fair warning, one of the other hats I wear is the chief custodian of the
U-Boot project.

Note that on most architectures in modern times the device tree is used
to pass in initrd type information and "initrd=3D" on the command line is
quite legacy.

But what do you mean UEFI "consumes" initrd=3D ?  It's quite expected that
when you configure grub/syslinux/systemd-boot/whatever via extlinux.conf
or similar with "initrd /some/file" something reasonable happens to
read that in to memory and pass along the location to Linux (which can
vary from arch to arch, when not using device tree).  I guess looking at=20
Documentation/x86/boot.rst is where treating initrd=3D as a file that
should be handled and ramdisk_image / ramdisk_size set came from.  I do
wonder what happens in the case of ARM/ARM64 + UEFI without device tree.

That said, no the comment is wrong.  It's not "since 11/2018" but "since
the 1990s".  And it doesn't provide any sort of link / context to the
boot loader specification project or similar that explains the cases
when a non-filename "initrd=3D" would reasonably (or unreasonably but
happens in reality) be removed.

I would go so far as to suggest that adding special handling for some
x86 setups is the wrong to place to start / further deprecate how other
architectures and firmwares handle a given situation.  I'm only chiming
in here as I saw this commit go by on LWN and wanted to see how this was
different from the traditional usage of initrd=3D in the rest of the
kernel (it's not) and then saw the otherwise unrelated new comment being
added.

--=20
Tom

--ZGfVcqCQYT4RlWas
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAl7xFz4ACgkQFHw5/5Y0
tyzDqwv/Q4YjI0nwVltVEupqLyeqOBD765TmWdoXzJ69K42gTsYDHTN4qXT+RRX9
2zxJwh/9egkyuuI05VXRY+NzkqVcmkyAoYnZg648G4bn8DTfPg4vYFMAVDy1lNS8
HpnVJjAzDHD4O6yaAMDBP4O9WOp5K55yXyoSv04bY8wa7Bf3B2SoSxppZjVbwdxV
RKzn0ypZXfYJ3Ob7hrS25o8Q+MCk2KcJqSg3dkYpDnud2TI40Ltwm0EdEQJHeN3s
qVr5J22V3fIJnkPKiROnqiUhSEA8H+fuQrBFQKjLN09pZHMtTkpFHQxiI6ATjE+s
/6xGBwtu9X8ipBiIe+uoiKmBXzSX3KEKLrtthTqzPnWmlPZZhtzfDRoAWSztj02s
PE1zkN++35i6dczldwaPqCUcsUpcgHaftsmty4bH7IGLYb6EAYJL5GP7fEm+KIow
ye44TLLSdPu9RAMRd3EfnKwFGgjC+AQxV5DE0egkqjbEKugCmL3iSQZ6MnC+8mGK
bZc7OZbi
=NpoE
-----END PGP SIGNATURE-----

--ZGfVcqCQYT4RlWas--