Re: memory allocator enhancements...

[phcoder <phcoder@gmail.com>]

phcoder wrote:
> 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")

IMO this code needs to integrate with normal mm. Also mm can have a 
machine-dependent backend to allocate more pages or to do claimmap on 
pages normally not supposed to be in mm

> 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