I think we should create a new loader(maybe separating common linux and
android code into a lib) for this rather than a filesystem because it would
simplify grub.cfg files.
Also in case we'll ever need to support 2ndloader(I'm like 99% sure this
will never happen though) it would be easier to implement this in the
android loader rather than adding another command for that.
On Fri, Jan 29, 2016 at 3:12 PM, Shea Levy <s...@shealevy.com> wrote:
> On 2016-01-29 04:18, Andrei Borzenkov wrote:
>
>> On Fri, Jan 29, 2016 at 2:48 AM, <s...@shealevy.com> wrote:
>>
>>> Is it important that this go the "dedicated loader" route? It looks like
>>> quite a bit of work to abstract out the functionality of the "linux" and
>>> "initrd" commands in a way that enables reuse from other commands.
>>>
>>>
>> "It needs work" is rather weak argument against doing something.
>>
>> Actually it is not that much work, at least for initial
>> implementation. You could use "anonymous" files that are instantiated
>> on the fly (see verify command for example how to do it); that needs
>> minimal changes to linux/initrd to split out front end part that opens
>> files. All further processing would then be shared.
>>
>>
> OK, will take this approach.
>
>
>>
>>> 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
>>>
>>
>> Dealing with stored command line on grub shell level is not simpler
>> due to fun with word splitting and quoting. Working with it in C would
>> be easier. But here again is the question if we can treat Android as
>> Linux. E.g. does Android support (or required to support) vga and mem
>> parameters? If not, this part is obviously redundant.
>>
>>
> At least for android-x86 (the part I'm most familiar with), android is
> just a normal Linux as far as bootloading/command line is concerned.
>
>
>
>> Nothing prevents Android command from supporting extra kernel
>> arguments that override stored command line.
>>
>> 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" <grub-devel@gnu.org>
>>>
>>> To:
>>> "The development of GNU GRUB" <grub-devel@gnu.org>
>>> Cc:
>>> "Shea Levy" <s...@shealevy.com>
>>> 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 <s...@shealevy.com> 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
>>> Grub-devel@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
