On Thu, Jan 24, 2008 at 07:49:23PM +0800, Bean wrote: > On Jan 24, 2008 7:32 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > > Sorry, my question was confusing; what I meant is, where is it located when > > core.img is started. But Just checked in our Linux loader, and it seems to > > be > > at a very high address. > > > > However, a very high address doesn't garantee that it won't be overwritten > > by > > lzo decompression, just makes it less likely. > > > > Overall, this is why I don't like having to stick to a particular boot > > mechanism. If our goal is overcome the size limit in memdisk, why not > > design > > the boot mechanism ourselves? > > I'm not familiar with multiboot spec, does it support arbitrary kernel size ?
Sorry I don't know, you'd have to check. However, my point is more about the loadee than the loader. We provide a multiboot image, which can also be a linux image with lnxboot.img, however, this image needs to be very small, because it's intended usage is with grub-setup, and that is why we only put the minimal stuff in it, and compress it. 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! I think we need to discuss more about the situation you want to solve. Who is going to load GRUB in lnxboot form + memdisk image? Where is it going to load that from? If GRUB can access the same media, why not use loopback to add a virtual disk based on the filesystem image, instead of loading it in memory? -- 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