Re: [PATCH] memdisk plus lnxboot extension

[Robert Millan <rmh@aybabtu.com>]

On Thu, Jan 24, 2008 at 07:49:23PM +0800, Bean wrote:
> On Jan 24, 2008 7:32 PM, Robert Millan <rmh@aybabtu.com> 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 /.)