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;
From:   Shea Levy <shea@shealevy.com>
To:     Palmer Dabbelt <palmer@sifive.com>, Arnd Bergmann <arnd@arndb.de>,
        Olof Johansson <olof@lixom.net>
Cc:     linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.
In-Reply-To: <mhng-72f2db2a-5505-4736-b39b-66b85db4d21c@palmer-si-x1c4>
References: <mhng-72f2db2a-5505-4736-b39b-66b85db4d21c@palmer-si-x1c4>
Date:   Fri, 20 Apr 2018 18:50:09 -0400
Message-ID: <87muxx1oim.fsf@xps13.shealevy.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha256; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi Palmer,

Palmer Dabbelt <palmer@sifive.com> writes:

> On Wed, 18 Apr 2018 04:10:16 PDT (-0700), shea@shealevy.com wrote:
>> Hi all,
>>
>> Shea Levy <shea@shealevy.com> writes:
>>
>>> This function is effectively identical across 14 architectures, and
>>> the generic implementation is small enough to be negligible in the
>>> architectures that do override it. Many of the remaining divergent
>>> implementations can be included in the common code path in future,
>>> further reducing code duplication and sharing improvements between
>>> architectures.
>>>
>>> Series boot-tested on RISC-V (which now uses the generic
>>> implementation) and x86_64 (which doesn't).
>>>
>>> v6: Add information about build/run testing.
>>> v5: Add more complete commit messages.
>>> v4: Use weak symbols instead of Kconfig.
>>> v3: Make the generic path opt-out instead of opt-in.
>>> v2: Mark generic free_initrd_mem __init.
>>>
>>> Signed-off-by: Shea Levy <shea@shealevy.com>
>>> ---
>>>  init/initramfs.c | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/init/initramfs.c b/init/initramfs.c
>>> index 7e99a0038942..c8fe150f958a 100644
>>> --- a/init/initramfs.c
>>> +++ b/init/initramfs.c
>>> @@ -526,6 +526,11 @@ extern unsigned long __initramfs_size;
>>>  #include <linux/initrd.h>
>>>  #include <linux/kexec.h>
>>>=20=20
>>> +void __init __weak free_initrd_mem(unsigned long start, unsigned long =
end)
>>> +{
>>> +       free_reserved_area((void *)start, (void *)end, -1, "initrd");
>>> +}
>>> +
>>>  static void __init free_initrd(void)
>>>  {
>>>  #ifdef CONFIG_KEXEC_CORE
>>> --=20
>>> 2.16.2
>>
>> This series has been quiet for a few weeks other than picking up some
>> arch-specific acks. What is the next step here?
>
> I'm not sure.  I don't really think it's sane for the RISC-V tree because=
 it=20
> touches so many architectures -- I haven't looked closely, though.

Yeah, I think that makes sense.

> IIRC=20
> there's a slight behavior change to the RISC-V port, which I'd be OK taki=
ng=20
> through my tree (and then obviously the RISC-V cleanup as well, unless it=
 goes=20
> in as a whole patch set).
>

So currently the behavior for RISC-V is changed by simply deleting the
arch-specific free_initrd_mem, which was a noop. Would you like me to
first submit a patch to have the arch-specific free_initrd_mem and then
change that in this series?

>
> For the IRQ cleanup I currently have in flight
>
> * Add the generic support
> * Move every arch over (RISC-V is in, the rest aren't yet)
> * Clean up a bit now that everyone is generic
>
> That lets all the arch-specific patches go in parallel, but can be a bit =
of a=20
> headache to manage.

With the current series, the first patch could go in on its own and all
of the arch-specific patches can go in in parallel if we wanted to, but
beyond the above-suggested implementation of the RISC-V free_initrd_mem
there's no real reordering meaningful here.

>
> I'm adding Arnd and Olof, as they know a lot more about Linux than I do.=
=20=20
> Here's the top-level of the v4 patch set: https://lkml.org/lkml/2018/3/28=
/744

And here's the top-level of v6, the latest: https://lkml.org/lkml/2018/4/1/=
50

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

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

iQIzBAEBCAAdFiEE6ESKvwKkwnxgMLnaXAvWlX2G/icFAlrabqEACgkQXAvWlX2G
/ifgqxAAjC5L2OT4nPpqrl/EjvM/XDJrX8RoUK+9gQehQvzHvbf1kHYN/htRHd4m
4g78tcFpJzyJPdPkVwXuVa/kg7bs229+c5sg81/brfHsj4J8oRCTt94johmDy+sT
Gd4ESra2b5WbC5w31CvTiwgGnlQgH47D8O4Vgs3X+X2OQqRTTEzmHP6iEtCSh+6k
BcVMw44lN731OlG0Bg7pMWY9QMu7mQ9VxksIBkEpFNWU3Rrn+ikXuLXhgaOZ5euL
yUmC/XYiqldRcIDhJooQmzm6zBZaBVtIvdiBAzzYsC5B0sSCqb4X+922WjIwLDte
9IxYUekCfbbeIRUb1gnGmVw+bIWdXre/h5sbkmjnZCuUIXYXRvgVKxH9Gljp/lcH
Tn91t2ajNJkQVgqoCNW23osRBwzND6DAF3cMIjHm4g8xBYkP+S0nF/sDmGs0oNLv
aHg3ma51NJwPc0eXP35iyCQJ5uEmilwW4DeM7FzhjJ+iZuTDzbCidDqrSDvCyN1Y
Z0JgivNuM88yhDDkRunb3YtO3BCi1uNtEn+TYhMz4ztWfijVoC/dhbOyPqmMD15Z
5VrjbQYpSLEI49RM/3IwuHHEoUkvCtqWwUlRuUlp+58NPEYlOWFfdwLiOgzp37AA
Z4Sk6AXtpoZvhQvmamj97hiw4RYtXG4J/2CIo+Sxf2JIboxFyf0=
=OpA3
-----END PGP SIGNATURE-----
--=-=-=--