All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Gerards <metgerards@student.han.nl>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: grub_machine_fini
Date: Sun, 10 Apr 2005 21:28:07 +0200	[thread overview]
Message-ID: <87r7hi8m9k.fsf@student.han.nl> (raw)
In-Reply-To: <b7cd8e7c27103002c4fc846c9fe5e2b4@penguinppc.org> (Hollis Blanchard's message of "Thu, 7 Apr 2005 10:31:53 -0500")

Hollis Blanchard <hollis@penguinppc.org> writes:

> The thing is, modules were loaded into heap memory. When we "release"
> that memory, Apple OF (remember, running in translated mode) unmaps it
> or makes it otherwise inaccessible. The very next function called
> after grub_machine_fini is the boot function pointer, which points
> into a module. Some sort of exception occurs (probably a "missing
> instruction mapping"), causing OF to fall over (and it's impossible to
> get any debug info).
>
> In other words, either:
> - the boot function must be part of the core, not in a module
> - or we cannot release heap memory

This is, AFAIK, already the case.  From kern/loader.c:

grub_err_t
grub_loader_boot (void)
{
  if (! grub_loader_loaded)
    return grub_error (GRUB_ERR_NO_KERNEL, "no loaded kernel");

  grub_machine_fini ();
  
  return (grub_loader_boot_func) ();
}

So grub_machine_fini and the call to the loader are both in the core.
The main problem is the loader itself is not.  The
grub_loader_boot_func is a function pointer to the boot function of
the active loader.

> If we remove the release call, then all that's left are those two
> _fini calls, which do almost nothing themselves. Also, we may want to
> print debug messages after this point, so grub_console_fini doesn't
> make sense here (luckily it doesn't actually stop grub_printf from
> working)...
>
> So I'm not sure how to use grub_machine_fini properly...?
>
> The good news is that when I comment out the release call, I can boot
> Linux again.

So the best thing to do is commenting this out in CVS and thinking
about a better solution.


How about this... I assume every loader on the PPC is just a call to
some address with some arguments.  Before that call is made some stuff
is set up.  For example the linux loaders sets up bootargs.  So what
we can do is change the boot function so it does not make the actual
call and just prepares for that.  The loader specific boot function
could return some information about the address that kern/load.c
should jump to and how to set up the arguments, etc.

So if we implement this, the loader can be properly unloaded after it
did the set up.  So the new function would look, basically, like this:

grub_err_t
grub_loader_boot (void)
{
  if (! grub_loader_loaded)
    return grub_error (GRUB_ERR_NO_KERNEL, "no loaded kernel");

  grub_loader_boot_func (&bootinfo);

  grub_machine_fini ();

  ... some code to boot the machine using bootinfo ...
}


Of course it will not work like this if bootinfo is stored on the
heap.  So you could use alloca or something like that.  But I hope you
understand the basic idea.

What do you think?

Thanks,
Marco




      reply	other threads:[~2005-04-10 19:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-15  0:15 grub_machine_fini Yoshinori K. Okuji
2005-02-15 20:41 ` grub_machine_fini Marco Gerards
2005-04-07 15:31   ` grub_machine_fini Hollis Blanchard
2005-04-10 19:28     ` Marco Gerards [this message]

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=87r7hi8m9k.fsf@student.han.nl \
    --to=metgerards@student.han.nl \
    --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.