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

[Vladimir 'phcoder' Serbinenko]

On Mon, 15 Feb 2016 04:42 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).

Actually we already have support for unsized files. It's marginal due to issues you detailed. As long as we error or correctly, it's fine. I looked thorough the code and there is some bad code around this issue which needs to be fixed anyway like overflows. I'll prepare a patch

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


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