grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 2/3] i386: Add support for loading from android bootimg


From: Andrei Borzenkov
Subject: Re: [PATCH v3 2/3] i386: Add support for loading from android bootimg
Date: Mon, 15 Feb 2016 06:41:16 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

14.02.2016 23:58, Seth Goldberg пишет:
> 
> 
>> On Feb 14, 2016, at 5:26 AM, Vladimir 'phcoder' Serbinenko
>> <address@hidden> wrote:
>> 
>> 
>> 
>> Le dim. 14 févr. 2016 14:21, Shea Levy <address@hidden> 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)+<number of sectors> 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?
> 
> I think syntax that allows a whole disk to be specified (e.g. To the
> multiboot module command so a disk image can be passed that way) is a
> great idea.
> 

The problem is that "whole" disk may not have define length which in
turn means quite a lot of rewrite everywhere (most loaders assume that
file they get has size and this size is what they load).

I assume you do know in advance whether you have file or device. In
which case what about extending probe to return size and do

probe --set size --size $dev
multiboot ($dev)+$size




reply via email to

[Prev in Thread] Current Thread [Next in Thread]