|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.|
----- Original Message -----
"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;
> + uint8_t name[BOOT_NAME_SIZE];
> + uint8_t cmdline[BOOT_ARGS_SIZE];
> + uint32_t id;
> + 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
can transparently handle any forward and backward compatibility
without impacting existing grub.cfg.
Grub-devel mailing list