Another idea is to allocate invalidatable blocks like disk cache in the
middle of the memory. It would decrease the memory fragmentation and if
it conflicts with any other allocation it can be easily invalidated
Vesa Jääskeläinen wrote:
- Seems to be a bit tricky to patch relocation info properly (at least
this is what I was last debugging). Ideas are welcome. Perhaps my code
was not just modified properly...
In my efiemu patch I needed to do some similar things (virtual
addressing code vs physical addressing code). You may look at my efiemu
patch
2. Allocate memory for BIOS extensions in order to support BIOS drive
mapping and El Torito or what ever someone needs.
- Probably need to make hole to memory map that is passed to OS so
allocated memory needs to be at end of lowmem so no holes within low
memory are present
I propose to integrate this with grub_machine_mmap_iterate. It would be
like
grub_mmap_iterate - similar to grub_machine_mmap_iterate but with holes
created by grub itself
grub_mmap_register (start,length, type) - create a memory block of type
TYPE. This way all loaders will pass "perforated" map to their kernels.
As for kernels using BIOS I would code int15 handler.
- Perhaps this should be only done at last step of boot process. Eg
allocate first memory to high mem and then when boot decision has been
made, then allocate to low mem and make necessary hooks
The patch to do this "preboot hooks" is pending since september
Are there any other needs?
For xnu resume to work fine I need to allocate a huge chunk of memory
for hibernate image (whole memory minus few MB). It can be anywhere but
must be contiguous.
So what does people feel about these changes. I am afraid if too much
freedom is given it will make it complex...
Thanks,
Vesa Jääskeläinen
_______________________________________________
Grub-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/grub-devel