On Mon, Dec 24, 2007 at 09:27:05PM +0800, Bean wrote: > On Dec 24, 2007 9:09 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > > I was thinking in moving it to malloc'ed memory, which has the advantage > > that > > you no longer need to remember a particular region is hardcoded for memdisk > > (also, it hinders portability on platforms where top of memory is reserved). > > > > but this doesn't solve the problem about its original region being corrupted > > (by payload loaders) before we have a chance to copy it. > > In that case, you can copy the memdisk back to conventional memory, > alongside with modules. > In startup.S: > > codestart: > ... > /* copy modules before cleaning out the bss */ > movl EXT_C(grub_total_module_size), %ecx > movl EXT_C(grub_kernel_image_size), %esi > addl %ecx, %esi > > -> > movl EXT_C(grub_total_module_size), %ecx > + addl EXT_C(grub_memdisk_image_size), %ecx > movl EXT_C(grub_kernel_image_size), %esi > addl %ecx, %esi
Doesn't this add a restriction on the maximum usable size, when it collides with the assorted amenities in the 640 kiB / 1024 kiB area ? > > > I also recommend to add a variable grub_memdisk_image_base in > > > startup.S, normally, this value will be zero, > > > > That's in my patch already. Or did you mean something else? > > But i only see the grub_memdisk_image_size, not the base address. Ah right; well it's still there, just not directly: + return 0x100000 + (grub_kernel_image_size - GRUB_KERNEL_MACHINE_RAW_SIZE) + grub_total_module_size; those two variables are from startup.S as well, IIRC. Although it might make sense to move them as a precalculated address. The code to compute it probably takes more kernel space than the address itself.. -- 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
