Hello. As appeared multiple times grub2's memory management can't handle some problems. 1) First of all it manages grub_malloc and os_area separately which forces initialisation code to split memory into two parts. Let's take a case of initrd for linux and solaris both having size of 270 MiB. And also a machine with 512 MiB memory. Linux loader puts initrd in os_area but multiboot allocates memory with grub_malloc. So in this configuration only one will work. One solution is to make multiboot loader use os_area but then non-loaders may need big amounts of memory too (e.g. graphics) 2) Cross-firmware. Currently every loader uses firmware functions to claim memory ranges. These functions need to be abstracted and work for systems where either grub (e.g. on BIOS) or firmware (e.g. on EFI) is owner of memory 3) Hibernation. At least one loader (xnu) needs to supply a hibernation image to the kernel. This is particularly nasty because it has to be in one chunk and can be up to 100-epsilon percent of RAM. So I propose the following adjustments: 1) When doing grub_memalign (); caller can optionally specify an allocation policy. On BIOS there would be 3 allocation policies: DEFAULT, KERNEL and LOWMEM. DEFAULT will allocate starting at the end of memory, KERNEL starting from the start of memory and ignoring everything upper than 4 GiB. This decision is to make big allocation containing kernel and modules needed for loader to be easily expandable when adding modules. 2) grub_request_cells will allow asking for a specified range to be unmanaged by memory system. This would allow e.g. to load kernel at 1MiB mark grub_request_cells can only request ranges aligned on cell boundaries. A separate function grub_request available from a module will allow sub-cell requests by maintaining a linked list of partialy allocated cells. You can see my current progress on http://repo.or.cz/w/grub2/phcoder.git branch mm. Currently grub_request is mapped to grub_request_cells. Everything compiles only on bios and I haven't launched it at all yet. In other words you shouldn't boot with it yet unless in vm you don't care about -- Regards Vladimir 'phcoder' Serbinenko
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
