[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: memory allocator enhancements...

From: phcoder
Subject: Re: memory allocator enhancements...
Date: Sun, 05 Apr 2009 14:49:42 +0200
User-agent: Thunderbird (X11/20090318)

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...

Vesa Jääskeläinen

Grub-devel mailing list


Vladimir 'phcoder' Serbinenko

reply via email to

[Prev in Thread] Current Thread [Next in Thread]