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

[Seth Goldberg]

> On Feb 14, 2016, at 7:41 PM, Andrei Borzenkov <address@hidden> wrote:
> 
> 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

  Yes I'm referring to devices for which size is
known mostly, though it would also be interesting to support on-demand loading 
of devices that don't have a fully known size.  The probe syntax is 
also acceptable though some syntactic sugar would also be appreciated ;).

  Thanks,
  --S

> 
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel