Re: [PATCH v2] Initial support for the android bootimg filesystem.

[Andrei Borzenkov]

29.01.2016 20:37, Vladimir 'phcoder' Serbinenko пишет:
> I actually think that both approaches have pros and cons. Can we settle on
> a design before plunging forward?
> We should have feature parity between Android image and plain linux. I.a.
> it should be possible to replace or append initrd and command line. Doing
> this with a single command is tricky. Does bootimg come with a command line
> or is it just a bundle of Linux image and initrd? Have you considered
> making linux recognize androidimg and pull linux out of it? Adding
> androidimg: alongside newc: syntax to initrd?
> 

As far as I understand this is single file that packs kernel, initrd and
command line in one unit.

https://www.compulab.co.il/workspace/mediawiki/index.php5/Android:_Boot_image

I am not sure it is correct to treat it as free standing Linux kernel.

> Le ven. 29 janv. 2016 15:13, Shea Levy <address@hidden> a écrit :
> 
>> On 2016-01-29 04:18, Andrei Borzenkov wrote:
>>> On Fri, Jan 29, 2016 at 2:48 AM,  <address@hidden> 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" <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
>>>
>>> _______________________________________________
>>> Grub-devel mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>