[Top][All Lists]

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

Re: grub_machine_fini

From: Marco Gerards
Subject: Re: grub_machine_fini
Date: Sun, 10 Apr 2005 21:28:07 +0200
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)

Hollis Blanchard <address@hidden> 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_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_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?


reply via email to

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