On Tue, Jul 31, 2007 at 10:55:09AM -0500, Hollis Blanchard wrote: > On 7/31/07, Robert Millan <[EMAIL PROTECTED]> wrote: > > On Mon, Jul 30, 2007 at 05:35:28PM -0500, Hollis Blanchard wrote: > > > > When GRUB_IEEE1275_FLAG_EFIKA_SECRET_AVAILABLE_REGION was set, > > > > release hardcoded 0x4000:0xffc000 region. > > > > > > Hmm, does this actually work? Since GRUB itself falls within that > > > regions, the grub_ieee1275_release() call will mark all the memory > > > that the GRUB kernel and modules occupy as free, which means they will > > > be clobbered by heap usage. > > > > Didn't think of this.. (by chance it worked here, though). How about using > > max(_end,0x4000) instead of 0x4000 ? > > > > (and adjusting region length not to overflow 0x1000000) > > That won't quite work because the modules are loaded in the area > immediately following the kernel. However, because they are added in a > post-processing step, we don't know their end address at link time. > > I think the simplest solution will be to allocate Efika's heap high, > as we talked about earlier. If the first "available" region is above > 4MB, just reserve 4MB and don't worry about where it is. In general we > should try to keep 4MB free, but at the end of the day it's Efika's > fault and probably won't be a big deal for them anyways.
Ok, let's do that. But what do we do if the first available region is just a few kBs below 4MB? Or if it's just too small? I think we need to determine what is the minimum heap size we want to accept, such that the ability to keep 4MB free still compensates having a small heap. Any suggestion? -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
