From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aV0M1-00048u-Ug for mharc-grub-devel@gnu.org; Sun, 14 Feb 2016 12:21:01 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35391) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aV0Lz-000463-2a for grub-devel@gnu.org; Sun, 14 Feb 2016 12:20:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aV0Lt-0003nQ-TG for grub-devel@gnu.org; Sun, 14 Feb 2016 12:20:59 -0500 Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]:34224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aV0Lt-0003my-E2 for grub-devel@gnu.org; Sun, 14 Feb 2016 12:20:53 -0500 Received: by mail-lf0-x234.google.com with SMTP id j78so76786415lfb.1 for ; Sun, 14 Feb 2016 09:20:53 -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=+BaehDhEYFK1bPYw7S3pLLm1b3Ep4rcQwwsiEyUx8Mk=; b=SIpHyVG4jnRIUjEokame7Fe2lPDBYPGUBQKS1oER1vlU42uKmAbQt2v43X7kkcrfwY x3UT4VqWjIWAI98qeiDF19YElMN8HZ6026g9HPvRRo/dt0LnAvB4b+iVPRdvKQxnGj9C VvL3FvVqCs//mokscFXQ5GOInVX3UNqBB8/NyrnL1SJlMxmLxXAGJtOxLoBw2gH6djnd RhTDuUhJmFt8QuPaKPcB5xQCNNn6u5rbmQuLgCUYrFeYEWJaXZ+sYZUopenYJaCw0kMw zIIVYeHQxJp7nfeU69lw7Bi2fN/VzJ1fOjERuf/eC5j9/aHK9LBOgjFQtWN73IAdahHd 72Ng== 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=+BaehDhEYFK1bPYw7S3pLLm1b3Ep4rcQwwsiEyUx8Mk=; b=Jv72SkHLXW4M5BC2QA5PeWA3erwQCYoBsie7neNdDrD5zKdnzx8iY7n1SsK/kXHBcR FYRqC52rQV7iQ56KHbeEua401p9GgqfmnQ78E+UmecBM3JssgmVW8TVMI7mBMxCerHKF w6i3QMaw5CWflDkceDUuudY/5h9k7AzkWGnU3/J+aBjwAU3e3L9Y0mtAwVd9nN8qFGRa DpqyIrtH2GCToAvssNf7wehWU6mzmNKKxURxeykvCidDu9A8LdTdneUAdxR+ualEME/5 pnXgDx1IelNLlPZdQI77nv7b9WkNH6wStP6mNwF1+O3BT/2clVNkUMrNUqPO5+qdnHHd 1n6g== X-Gm-Message-State: AG10YOQJ5f1u01UWwf/jepk+0jg67TzN4LJHlEit8vre4zSz18g6rjBYPqbeUZUfxcDSAQ== X-Received: by 10.25.18.214 with SMTP id 83mr4254325lfs.52.1455470452443; Sun, 14 Feb 2016 09:20:52 -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 p191sm3113554lfp.39.2016.02.14.09.20.50 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 14 Feb 2016 09:20:51 -0800 (PST) Subject: Re: [PATCH v3 2/3] i386: Add support for loading from android bootimg To: grub-devel@gnu.org References: <1454964459-28213-1-git-send-email-shea@shealevy.com> <1454964459-28213-3-git-send-email-shea@shealevy.com> <56BE1B60.5060900@gmail.com> <7384a36941a77cced1fde7e3d084280a@shealevy.com> <2b7ecf3a0dda2687029878e0e745bd73@shealevy.com> <56BE4BB7.6040203@gmail.com> From: Andrei Borzenkov X-Enigmail-Draft-Status: N1110 Message-ID: <56C0B772.9070104@gmail.com> Date: Sun, 14 Feb 2016 20:20:50 +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:c07::234 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: Sun, 14 Feb 2016 17:21:00 -0000 14.02.2016 16:26, Vladimir 'phcoder' Serbinenko пишет: > Le dim. 14 févr. 2016 14:21, Shea Levy a écrit : > >> This patch uses grub_file_open, but the android bootimg is a disk, not >> a file. You mentioned something about file_offset_open, but that also >> expects an input file, not a disk. Should I modify your patch with my >> code I wrote to create a grub_file_t from an android_bootimg disk >> device, or is there another approach? >> > We already have syntax (hd0,1)+ that we use for i.a. > chainloader perhaps we should extend it to have (hd0,1)+ meaning whole disk > as file? Or even allow the disk to be opened with GRUB_file_open? I'd like > a second opinion on this. Andrei, what do you think? > Yes, it was discussed just recently on help-grub. I'd prefer ($dev)+ as explicit indication that we want blocklists. The practical problem is that we must allow unknown file size. I am not sure how deep changes are required. But as the trivial example, what "ls -l ($dev)+" is going to output? Is "test -s ($dev)+" true or false when size is unknown?