> On Feb 14, 2016, at 7:41 PM, 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). > > 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 > 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
