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 <s...@shealevy.com> a écrit : > >> 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 > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
