[PATCH] x86/setup: refactor initrd reservation

[PATCH] x86/setup: refactor initrd reservation

[Alexander Kuleshov]

The check and definitions related to ramdisk are similar in the
early_reserve_initrd() and reserve_initrd(). So we can get rid of
early_reserve_initrd() and and use late or early algorithm for
initrd reservation depends on reserve_initrd() parameter value.

Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
---
 arch/x86/kernel/setup.c | 29 +++++++++--------------------
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d3d80e6..f6f38b0 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -349,20 +349,7 @@ static void __init relocate_initrd(void)
 		relocated_ramdisk, relocated_ramdisk + ramdisk_size - 1);
 }
 
-static void __init early_reserve_initrd(void)
-{
-	/* Assume only end is not page aligned */
-	u64 ramdisk_image = get_ramdisk_image();
-	u64 ramdisk_size  = get_ramdisk_size();
-	u64 ramdisk_end   = PAGE_ALIGN(ramdisk_image + ramdisk_size);
-
-	if (!boot_params.hdr.type_of_loader ||
-	    !ramdisk_image || !ramdisk_size)
-		return;		/* No initrd provided by bootloader */
-
-	memblock_reserve(ramdisk_image, ramdisk_end - ramdisk_image);
-}
-static void __init reserve_initrd(void)
+static void __init reserve_initrd(int early)
 {
 	/* Assume only end is not page aligned */
 	u64 ramdisk_image = get_ramdisk_image();
@@ -374,6 +361,11 @@ static void __init reserve_initrd(void)
 	    !ramdisk_image || !ramdisk_size)
 		return;		/* No initrd provided by bootloader */
 
+	if (early) {
+		memblock_reserve(ramdisk_image, ramdisk_end - ramdisk_image);
+		return;
+	}
+
 	initrd_start = 0;
 
 	mapped_size = memblock_mem_size(max_pfn_mapped);
@@ -398,10 +390,7 @@ static void __init reserve_initrd(void)
 	memblock_free(ramdisk_image, ramdisk_end - ramdisk_image);
 }
 #else
-static void __init early_reserve_initrd(void)
-{
-}
-static void __init reserve_initrd(void)
+static void __init reserve_initrd(int early)
 {
 }
 #endif /* CONFIG_BLK_DEV_INITRD */
@@ -850,7 +839,7 @@ void __init setup_arch(char **cmdline_p)
 	memblock_reserve(__pa_symbol(_text),
 			 (unsigned long)__bss_stop - (unsigned long)_text);
 
-	early_reserve_initrd();
+	reserve_initrd(1);
 
 	/*
 	 * At this point everything still needed from the boot loader
@@ -1135,7 +1124,7 @@ void __init setup_arch(char **cmdline_p)
 	/* Allocate bigger log buffer */
 	setup_log_buf(1);
 
-	reserve_initrd();
+	reserve_initrd(0);
 
 #if defined(CONFIG_ACPI) && defined(CONFIG_BLK_DEV_INITRD)
 	acpi_initrd_override((void *)initrd_start, initrd_end - initrd_start);
-- 
2.7.0.25.gfc10eb5

Re: [PATCH] x86/setup: refactor initrd reservation

[Andy Shevchenko]

On Fri, Feb 5, 2016 at 7:38 PM, Alexander Kuleshov
<kuleshovmail@gmail.com> wrote:
> The check and definitions related to ramdisk are similar in the
> early_reserve_initrd() and reserve_initrd(). So we can get rid of
> early_reserve_initrd() and and use late or early algorithm for
> initrd reservation depends on reserve_initrd() parameter value.

Perhaps: "Squash {early_,}reserve_initrd() to one function" would be
better for Subject line since it describes what you are doing here
(Answering question "What kind of refactor?").

Also if you have more argument (like .text size before and after) I
suppose it would have been passed faster.

> +static void __init reserve_initrd(int early)

Why int and not bool?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] x86/setup: refactor initrd reservation

[Alexander Kuleshov]

On Mon, Feb 8, 2016 at 9:56 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Fri, Feb 5, 2016 at 7:38 PM, Alexander Kuleshov
> <kuleshovmail@gmail.com> wrote:
>> The check and definitions related to ramdisk are similar in the
>> early_reserve_initrd() and reserve_initrd(). So we can get rid of
>> early_reserve_initrd() and and use late or early algorithm for
>> initrd reservation depends on reserve_initrd() parameter value.
>
> Perhaps: "Squash {early_,}reserve_initrd() to one function" would be
> better for Subject line since it describes what you are doing here
> (Answering question "What kind of refactor?").
>
> Also if you have more argument (like .text size before and after) I
> suppose it would have been passed faster.
>

Hello Andy, thanks for your suggestions. Will update it in second revision.