All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Rydberg <jrydberg@night.trouble.net>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] generic ELF loading
Date: Tue, 24 Oct 2006 22:48:39 +0200	[thread overview]
Message-ID: <87iri91lug.fsf@night.trouble.net> (raw)
In-Reply-To: <1161720181.23331.25.camel@basalt.austin.ibm.com> (Hollis Blanchard's message of "Tue, 24 Oct 2006 15:03:00 -0500")

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

Hollis Blanchard <hollis@penguinppc.org> writes:

>> The idea is very good. But I don't like that loaded areas are always allocated 
>> from the heap. GRUB has a staging area for OS images on i386-pc, and I prefer 
>> to load an image directly instead of consuming the heap.
>
> Actually I'm not using the heap, I'm just directly copying wherever
> phdr->p_paddr says to. That's not a good thing actually; in the future
> we should add some error checking to make sure we don't clobber GRUB
> itself.

Have you looked at how EFI solves this?  

They keep track of all memory regions, and with each region is a
"memory type" associated.  Whenever you allocate memory you change the
type of the region (from "free") to some that makes sense (could be
"loader data", "disk cache", ...). You can only allocate memory that
is marked "conventional", meaning it is considered free.  The memory
region database is later feed to the operating system.  We could do
the same.

Is this case we could allocate the regions specified by the ELF image.
If any of the allocations fail we know there is something already
loaded there, or the image is faulty.

~j

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

  reply	other threads:[~2006-10-24 20:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-13 22:37 [PATCH] generic ELF loading Hollis Blanchard
2006-10-13 22:40 ` [PATCH] ppc64 Linux ELF loader Hollis Blanchard
2006-10-14 15:33 ` [PATCH] generic ELF loading Yoshinori K. Okuji
2006-10-14 17:23   ` Tristan Gingold
2006-10-24 20:41     ` Hollis Blanchard
2006-10-24 20:03   ` Hollis Blanchard
2006-10-24 20:48     ` Johan Rydberg [this message]
2006-10-24 20:45       ` Hollis Blanchard
2006-10-25  5:53     ` Yoshinori K. Okuji
  -- strict thread matches above, loose matches on Subject: below --
2006-10-14  3:03 Mao, Bibo
2006-10-24 20:21 ` Hollis Blanchard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87iri91lug.fsf@night.trouble.net \
    --to=jrydberg@night.trouble.net \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.