On Mon, 15 Feb 2016 04:42 Andrei Borzenkov <arvidj...@gmail.com> wrote:

> 14.02.2016 23:58, Seth Goldberg пишет:
> >
> >
> >> On Feb 14, 2016, at 5:26 AM, Vladimir 'phcoder' Serbinenko
> >> <phco...@gmail.com> wrote:
> >>
> >>
> >>
> >> Le dim. 14 févr. 2016 14:21, Shea Levy <s...@shealevy.com> 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
> 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

Reply via email to