grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] memdisk plus lnxboot extension


From: Bean
Subject: Re: [PATCH] memdisk plus lnxboot extension
Date: Thu, 24 Jan 2008 22:57:46 +0800

On Jan 24, 2008 10:25 PM, Robert Millan <address@hidden> wrote:
>
> On Thu, Jan 24, 2008 at 07:49:23PM +0800, Bean wrote:
> > On Jan 24, 2008 7:32 PM, Robert Millan <address@hidden> 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?

i'm thinking about the situation where the boot media is not
accessible, like pxe/cdrom. in this case, we can create core.img that
contain minimum modules, and initrd that contain other modules plus
font files and other data file. then, we can use loader like
pxelinux/isolinux to load them at the same time.

-- 
Bean




reply via email to

[Prev in Thread] Current Thread [Next in Thread]