Hi Paul, Than k you very much for your comments! Will revise the commit messages base on your comments. I have tested on VirtualBox but will test on VMWare before sending out V3.
Best Regards, Zide > -----Original Message----- > From: Paul Menzel <pmen...@molgen.mpg.de> > Sent: Monday, April 6, 2020 1:57 PM > To: Chen, Zide <zide.c...@intel.com> > Cc: The development of GNU GRUB <grub-devel@gnu.org> > Subject: Re: [PATCHv2] multiboot2: enable quirk-modules-after-kernel > > Dear Zide, > > > Thank you for posting version 2 of your patch. (Please add v2 to the > patch tag next time.) > > Maybe use the commit message summary below. > > > multiboot2: Implement quirk-modules-after-kernel > > Am 03.04.20 um 09:35 schrieb Zide Chen: > > In multiboot2, currently there is no way to control where to load the > > Maybe start with: In contrast to Mulitboot (v1), in Mulitboot 2, there > is currently … > > > modules. In case of user wants to reserve low address for particular > > usage, this quirk is useful to load the modules to higher address. > > > > This patch makes the quirk to multiboot2 by: > > So, implement the quirk quirk-modules-after-kernel to load modules after > the kernel for Multiboot 2 by reusing the implementation for Multiboot (v1). > > > - remove "ifndef GRUB_USE_MULTIBOOT2" that is related to this logic. > > - define separate variables for both multiboot and multiboot2, e.g. > > grub_multiboot_quirks, highest_load, etc. > > - in grub_multiboot2_load(): calculate the highest load address of raw > > image and assign it to grub_multiboot2_highest_load. > > - the existing code in multiboot_elfxx.c is able to calculate the > > highest_load for mutiboot2 already. > > > > At the end, the adjusted GRUB_MULTIBOOT(highest_load) is used as the > > lowest address to allocate memory for loading modules. > > Tested with VMware. ;-) _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
