Hello, one additional consideration is to let grub2 stay in memory even
after OS loads. This way it would be possibly to expose any
file/partition accessible through grub2 system as a virtual int13h disk.
For this to be a it's very desirable to put all modules that may need to
stay, the kernel and corresponding memory at the end of lowmem/uppermem.
For OS loading memory at fixed address may be allocated by functions
like grub_claimmap on ieee1275 (I have some code in this direction in my
patch "multiboot on EFI")
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
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel