[PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.
shea at shealevy.com
Wed May 9 04:15:24 PDT 2018
Shea Levy <shea at shealevy.com> writes:
> Hi Palmer,
> Palmer Dabbelt <palmer at sifive.com> writes:
>> On Wed, 18 Apr 2018 04:10:16 PDT (-0700), shea at shealevy.com wrote:
>>> Hi all,
>>> Shea Levy <shea at 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
>>>> 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 at 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>
>>>> +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
>>> 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
>> touches so many architectures -- I haven't looked closely, though.
> Yeah, I think that makes sense.
>> there's a slight behavior change to the RISC-V port, which I'd be OK taking
>> through my tree (and then obviously the RISC-V cleanup as well, unless it goes
>> 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
>> 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.
>> 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
What's the right next step here?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the linux-riscv