On Fri, Jan 25, 2008 at 01:04:34AM +0800, Bean wrote: > On Jan 25, 2008 12:55 AM, Robert Millan <[EMAIL PROTECTED]> wrote: > > On Thu, Jan 24, 2008 at 03:25:51PM +0100, Robert Millan wrote: > > > > > > You want to add a feature that only works when you have the ability to > > > load > > > images of an arbitrary size. However, if we had this ability we wouldn't > > > have > > > to compress core.img, or make it small in the first place. We would then > > > just create core.img of an arbitrary size, and include a memdisk of an > > > arbitrary size in it. But then we wouldn't need a feature to work around > > > the > > > size restriction in memdisk! > > > > Just discussed it with Marco on IRC, and he said we could load core.img in > > high > > memory, like in 0x100000 right away. This solves the size limit in memdisk > > which I think is the source of the problem. > > > > Of course, this collides with the OS load area, so we'd also need to add > > relocation in loader, as described in the "grub_dl_unload_all()" thread. I > > do even have unfinished code for this, although it may take a while to get > > it > > done properly (maybe we need to add features to memory manager or so). Does > > this work for you? > > i think this is great, we don't have to worry about memdisk size, and > no need for the initrd hack anymore.
Ok. I'll send my patch to the list later (not as a proposal for commit, but to start a discussion on what is the right way to do it). -- Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call… if you are unable to speak? (as seen on /.) _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
