[Top][All Lists]

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

Re: [PATCH] memdisk plus lnxboot extension

From: Robert Millan
Subject: Re: [PATCH] memdisk plus lnxboot extension
Date: Thu, 24 Jan 2008 12:32:44 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On Thu, Jan 24, 2008 at 11:40:25AM +0800, Bean wrote:
> On Jan 24, 2008 5:15 AM, Robert Millan <address@hidden> wrote:
> >
> > On Thu, Jan 24, 2008 at 05:04:56AM +0800, Bean wrote:
> > > On Jan 24, 2008 4:15 AM, Robert Millan <address@hidden> wrote:
> > > > The region where memdisk is normally put has no size limit, only the 
> > > > core
> > > > image itself does.  Why not load it at the same address?
> > >
> > > I just check, the lzo decompression will overwrite the area, so we
> > > can't copy initrd there.
> >
> > So where does your code copy it?
> currently, i don't copy it. i save the initrd address to variable
> grub_memdisk_image_addr, which is then used by grub_arch_memdisk_addr
> to locate the memdisk.

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?

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 /.)

reply via email to

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