| The main reason was that it wasn't clear how to easily reuse the code in the linux module to load the kernel and initrd; a secondary reason is to allow overriding the kernel command line or whatever provided in the bootimg. If there is a relatively straightforward path to fix the first one, though, I'm happy to do that and figure out ways to override later once the need actually arises, if ever.
~Shea
----- Original Message -----
From: "The development of GNU GRUB" <address@hidden>
To: "The development of GNU GRUB" <address@hidden>
Cc: "Shea Levy" <address@hidden>
Sent: Wed, 27 Jan 2016 10:22:34 +0300
Subject: Re: [PATCH v2] Initial support for the android bootimg filesystem.
On Tue, Jan 26, 2016 at 10:42 PM, Shea Levy <address@hidden> wrote:
> Currently, the kernel and, if present, the ramdisk are made available as
> regular files.
...
> +
> +struct boot_img_hdr
> +{
> + uint8_t magic[BOOT_MAGIC_SIZE];
> +
> + uint32_t kernel_size;
> + uint32_t kernel_addr;
> +
> + uint32_t ramdisk_size;
> + uint32_t ramdisk_addr;
> +
> + uint32_t second_size;
> + uint32_t second_addr;
> +
> + uint32_t tags_addr;
> + uint32_t page_size;
> + uint32_t unused[2];
> +
> + uint8_t name[BOOT_NAME_SIZE];
> +
> + uint8_t cmdline[BOOT_ARGS_SIZE];
> +
> + uint32_t id[8];
> +
> + uint8_t extra_cmdline[BOOT_EXTRA_ARGS_SIZE];
> +} GRUB_PACKED;
> +
What is the use case for exposing it as filesystem in the first place?
Dedicated android loader that reads them looks more logical.
Should this layout/content ever change in the future it will be near
to impossible to modify without breaking unknown number of users
relying on it; while simple
android hd1,msdos4
can transparently handle any forward and backward compatibility
without impacting existing grub.cfg.
_______________________________________________
Grub-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel
|