From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aPDDA-0006iR-CY for mharc-grub-devel@gnu.org; Fri, 29 Jan 2016 12:51:56 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPDD6-0006aj-SM for grub-devel@gnu.org; Fri, 29 Jan 2016 12:51:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aPDD2-00027N-G0 for grub-devel@gnu.org; Fri, 29 Jan 2016 12:51:52 -0500 Received: from mail-lb0-x233.google.com ([2a00:1450:4010:c04::233]:35506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPDD2-000271-1q for grub-devel@gnu.org; Fri, 29 Jan 2016 12:51:48 -0500 Received: by mail-lb0-x233.google.com with SMTP id bc4so45110408lbc.2 for ; Fri, 29 Jan 2016 09:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=yqFeAfBHEEMlvASebYgmL+fZFVXRm2LjAjHvgqme1dA=; b=ZZF15YOBckJu61TySw06z2ptO2/1Y+SxTLoVXyJilDsINB4bxa5ygxF6ZMLfb3n1OV uq/rBzLWTzEXPOlkdxKxpHLV4DnwXM3VRo6Qn45+zS4sE9ocTTtdBl7uEOJqa+mxAzMe npidYaCFdx9Xq10Cz+TInJ0prsuITyw9G2cVQQkm9pMBnqUYiqrETmmbHrGehZnDlvcK IHOWWxCc7O+Tm4+1vQdWFdIH0fZ+JEqzHZWlFaOXxjd+w/xNlIVMHUFEKm96tC74mIfq B8IzNj5tgoTKGnd4R6g5z2OtrJk2CVg4YHAULG65ETaAR+hAWUG/y5f69u5koxij0Dvm h4TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=yqFeAfBHEEMlvASebYgmL+fZFVXRm2LjAjHvgqme1dA=; b=JCH7QedH1mCeIY1oCYe6fJWES9B2dd9/mKr9K3AV96mokJ9P0VpCepdbQhkzz8ROoN ReRkTRTgA3WWaBh/wdPxqFW4Q4fDWrd3CxbRAP5ovnYfk3Mo1qgYMpDcWnKluV9Lf071 GGo8wzidABditFnjjfHkhn2M8lHKVIA0fME9/miFC8TV7bEloZIm/6D/3f4bv4oB+ERO OSLGWaGdj7blCK1+cEFguE4iMtwR9XT/FwK2edAG3ICtdeHbeL/9ZYpIIEk2TuRt7Oid jFJDLS7kdYaQZfSrOKbBitJeRt9aDGlV62HQZv/98WELEKGqFvLBspw6d/55K2vwg20X Ml1A== X-Gm-Message-State: AG10YOSuYt/sasiesaVKymriD4FFtuKFH0xlHB5KR09aac4X4tsXNazKB3MRpmKSueWQnA== X-Received: by 10.112.148.131 with SMTP id ts3mr3824999lbb.102.1454089907143; Fri, 29 Jan 2016 09:51:47 -0800 (PST) Received: from [192.168.1.41] (ppp109-252-76-159.pppoe.spdop.ru. [109.252.76.159]) by smtp.gmail.com with ESMTPSA id 88sm1665105lfr.44.2016.01.29.09.51.45 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jan 2016 09:51:45 -0800 (PST) Subject: Re: [PATCH v2] Initial support for the android bootimg filesystem. To: grub-devel@gnu.org References: <1cf383303135546a37c29c688f85327142ac55fc@atmail.dreamhost.com> <39de9fe252169e0cb83b1216667ea879e555a70c@atmail.dreamhost.com> <4e65ec6c24e6f28976d3458bdfcb9e15@shealevy.com> From: Andrei Borzenkov Message-ID: <56ABA6B0.4080708@gmail.com> Date: Fri, 29 Jan 2016 20:51:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::233 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 17:51:54 -0000 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 a écrit : > >> On 2016-01-29 04:18, Andrei Borzenkov wrote: >>> On Fri, Jan 29, 2016 at 2:48 AM, 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" >>>> >>>> To: >>>> "The development of GNU GRUB" >>>> Cc: >>>> "Shea Levy" >>>> 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 >>>> 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 >