[Top][All Lists]

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

Re: embedding filesystems in core image (Re: moving ata initialisation t

From: Robert Millan
Subject: Re: embedding filesystems in core image (Re: moving ata initialisation to a command)
Date: Mon, 24 Dec 2007 14:09:41 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On Mon, Dec 24, 2007 at 04:29:19PM +0800, Bean wrote:
> On Dec 22, 2007 8:18 PM, Robert Millan <address@hidden> wrote:
> >
> > Here's a new patch, with some cleanup.  The main difference is that 
> > memdisk.c
> > doesn't include any arch-specific code.
> >
> > I've spotted a memory management problem.  The memdisk image, at the 
> > location
> > that it's usually uncompressed, tends to collide with the payload loading
> > region (grub_os_area_{addr,size}).
> >
> > I'm not sure what would be a good solution to this.  Perhaps we could copy 
> > it
> > to dynamic memory in grub_memdisk_init() ?  However, if user plays with 
> > payload
> > images without booting them, and then loads memdisk.mod manually, things 
> > could
> > break.
> >
> > Although, embedding a memdisk image without embedding memdisk.mod is kind of
> > silly;  perhaps grub-mkimage shouldn't allow it.
> >
> > What do you think?
>  I think you can copy the memdisk to the end of memory, and in
> grub_machine_init, make sure to exclude this area:
>       grub_mm_init_region ((void *) (grub_os_area_addr + grub_os_area_size),
>                            quarter);
> ->
>       grub_mm_init_region ((void *) (grub_os_area_addr + grub_os_area_size),
>                            quarter - memdisk_size);

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.

> 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 loader like
> lnxboot.S can set it to the address of the external initrd image.

Sounds consistent with what lnxboot does, although I'm not sure how useful
it'd be.

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]