>> > - Low memory heap (useful to move code off kern/i386/pc/startup.S). >> Originally I thought of a path relocator32->relocator users->mm >> relocator32 is ready for next round of review but is untested. Now I >> think about it mm patch isn't actually dependent on relocator32, just >> you won't get some features (as loading big initrds and removal of >> os_area_size/os_area_addr fields) before relocator32 is used by all >> loaders. I will adjust mm patch to this and add >> .(text|data|bss)-lowmem section support. > > I don't understand, what is the relation between relocator in loaders and > low memory heap? Actually low memory heap is a special case of policy based allocation. My design is: I have up to 4 different policies (can be more by modifying defines but has to be hardcoded for performance reasons and multiple of 4 for alignment reasons) Every region knows which allocator it has to use together with which policy. Current allocators: -Skip. Don't use this region with given policy -First. Try to allocate as low as possible -Last. Try to allocate as high as possible -Second. Allocate second free chunk from region. It's what is used currently.
The idea behind that design is that often loaders need a big continuous chunk of memory so if loaders get memory from bottom and the rest takes memory from top we're likely to have a chunk of necessary size available. To take advantage of this design kernel area (first 3/4 of memory which aren't added to heap) has to be eliminated. For this to happen all loaders have to use relocator. However I can make patches without need of relocator (w/o eliminating kernel area). Just you won't get all the advantages of policy-based allocations > > I'll need to catch up with the lowmem heap discussion. What's the approach? > >> What about savedefault? Which savedefault way you prefer? > > I think it would be good to have. But I haven't followed on the savedefault > discussion, I just know it would build upon the existing envfile support. > >> > Bigger overhauls like the fancy menu >> I started splitting Collin's patches and actually only quite few need >> to go to the parts already present in grub2. Perhaps 1.97 can be >> brought to a state when gfxmenu can be compiled externally? > > Depends on how intrusive are those changes :-) > I'll present them and I'm ok if they are postponed. > -- > Robert Millan > > The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and > how) you may access your data; but nobody's threatening your freedom: we > still allow you to remove your data and not access it at all." > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
