by Joe Perches

[permalink] [raw]

Subject: Re: [PATCH v4 14/16] powerpc: Use generic free_initrd_mem.

On Wed, 2018-03-28 at 16:36 -0400, Shea Levy wrote:
> Signed-off-by: Shea Levy <[email protected]>

Most people seem to want some form of commit message
and not just your sign-off.

And btw:

It seems you used get_maintainer to determine who to
send these patches to.

I suggest you add --nogit and --nogit-fallback to the
get_maintainer command line you use to avoid sending
these patches to people like me that have done drive-by
cleanup work on these files.

2018-03-28 20:55:27

The first patch in this series added a weakly-defined generic
implementation, which is functionally identical to the
architecture-specific one removed here.

Series boot-tested on RISC-V (which now uses the generic
implementation) and x86_64 (which doesn't).

Signed-off-by: Shea Levy <[email protected]>
---
arch/parisc/mm/init.c | 7 -------
1 file changed, 7 deletions(-)

diff --git a/arch/parisc/mm/init.c b/arch/parisc/mm/init.c
index cab32ee824d2..3643399230f3 100644
--- a/arch/parisc/mm/init.c
+++ b/arch/parisc/mm/init.c
@@ -932,10 +932,3 @@ void flush_tlb_all(void)
spin_unlock(&sid_lock);
}
#endif
-
-#ifdef CONFIG_BLK_DEV_INITRD
-void free_initrd_mem(unsigned long start, unsigned long end)
-{
- free_reserved_area((void *)start, (void *)end, -1, "initrd");
-}
-#endif
--
2.16.2

2018-04-01 15:03:52

Hi all,

Shea Levy <[email protected]> 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 <[email protected]>
> ---
> 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
> --
> 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?

Thanks,
Shea

Attachments:

signature.asc (847.00 B)

2018-04-19 16:39:22

by Mark Salter

[permalink] [raw]

Subject: Re: [PATCH v6 05/16] c6x: Switch to generic free_initrd_mem.

On Sun, 2018-04-01 at 10:59 -0400, Shea Levy wrote:
> The first patch in this series added a weakly-defined generic
> implementation, which is functionally identical to the
> architecture-specific one removed here.
>
> Series boot-tested on RISC-V (which now uses the generic
> implementation) and x86_64 (which doesn't).
>
> Signed-off-by: Shea Levy <[email protected]>
> ---
> arch/c6x/mm/init.c | 7 -------
> 1 file changed, 7 deletions(-)
>
> diff --git a/arch/c6x/mm/init.c b/arch/c6x/mm/init.c
> index 4cc72b0d1c1d..a11cb657182a 100644
> --- a/arch/c6x/mm/init.c
> +++ b/arch/c6x/mm/init.c
> @@ -66,13 +66,6 @@ void __init mem_init(void)
> mem_init_print_info(NULL);
> }
>
> -#ifdef CONFIG_BLK_DEV_INITRD
> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> -{
> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> -}
> -#endif
> -
> void __init free_initmem(void)
> {
> free_initmem_default(-1);

Acked-by: Mark Salter <[email protected]>

2018-04-20 20:25:59

by Palmer Dabbelt

[permalink] [raw]

Subject: Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

On Wed, 18 Apr 2018 04:10:16 PDT (-0700), [email protected] wrote:
> Hi all,
>
> Shea Levy <[email protected]> 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 <[email protected]>
>> ---
>> 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
>> --
>> 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
touches so many architectures -- I haven't looked closely, though. IIRC
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).

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.

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

2018-04-20 22:53:29

by Shea Levy

[permalink] [raw]

Subject: Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

Hi Palmer,

Palmer Dabbelt <[email protected]> writes:

> On Wed, 18 Apr 2018 04:10:16 PDT (-0700), [email protected] wrote:
>> Hi all,
>>
>> Shea Levy <[email protected]> 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 <[email protected]>
>>> ---
>>> 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
>>> --
>>> 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
> touches so many architectures -- I haven't looked closely, though.

Yeah, I think that makes sense.

> IIRC
> 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

Attachments:

signature.asc (847.00 B)

2018-05-09 11:16:10

by Shea Levy

[permalink] [raw]

Subject: Re: [PATCH v6 01/16] initrd: Add weakly-linked generic free_initrd_mem.

Hi all,

Shea Levy <[email protected]> writes:

> Hi Palmer,
>
> Palmer Dabbelt <[email protected]> writes:
>
>> On Wed, 18 Apr 2018 04:10:16 PDT (-0700), [email protected] wrote:
>>> Hi all,
>>>
>>> Shea Levy <[email protected]> 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 <[email protected]>
>>>> ---
>>>> 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
>>>> --
>>>> 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
>> touches so many architectures -- I haven't looked closely, though.
>
> Yeah, I think that makes sense.
>
>> IIRC
>> 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?

Thanks,
Shea

Attachments:

signature.asc (847.00 B)