grub_dl_unload_all()

grub_dl_unload_all()

[Robert Millan]

Is GRUB supposed to always call grub_dl_unload_all() when preparing to
jump into a loaded multiboot image?

My problem:

  - On i386-pc, multiboot2 loader calls grub_multiboot2_real_boot(), which
    in turn calls grub_dl_unload_all(), thereby unloading all modules (and
    I assume, calling all _fini() routines).

  - On powerpc-ieee1275, multiboot2 loader calls the entry right away, without
    unloading modules. In fact, it CANNOT unload them because it may have just
    overwritten them when loading the image to the arbitrary address it has
    requested.

  - On i386-ieee1275, the sanest choice was to follow powerpc-ieee1275 and
    claim the region that our payload image requests (see
    loader/powerpc/ieee1275/multiboot2.c).  However, this implies inability
    to unload all modules.

How important is it to unload all modules?  What do you suggest?  Do we fix
everything to unload all modules (is that even possible?)?  Do we unload all
modules on i386-pc "because we can" and not do this on ieee1275 platforms?

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

Re: grub_dl_unload_all()

[Yoshinori K. Okuji]

On Wednesday 23 January 2008 20:58, Robert Millan wrote:
> Is GRUB supposed to always call grub_dl_unload_all() when preparing to
> jump into a loaded multiboot image?

Yes.

> How important is it to unload all modules?  What do you suggest?  Do we fix
> everything to unload all modules (is that even possible?)?  Do we unload
> all modules on i386-pc "because we can" and not do this on ieee1275
> platforms?

It is important so that we can make sure that all cleanups are executed before 
transferring control. For example, if serial settings have been tweaked by 
GRUB, they should be reverted to the original state. At least, this is 
considered to be a good manner. Another example is video settings. Let's say, 
GRUB changes video mode to show a fancy menu. Some operating systems may not 
work well in graphical mode, then GRUB must turn it back to text mode.

Okuji

Re: grub_dl_unload_all()

[Robert Millan]

On Thu, Jan 24, 2008 at 09:57:45AM +0100, Yoshinori K. Okuji wrote:
> > How important is it to unload all modules?  What do you suggest?  Do we fix
> > everything to unload all modules (is that even possible?)?  Do we unload
> > all modules on i386-pc "because we can" and not do this on ieee1275
> > platforms?
> 
> It is important so that we can make sure that all cleanups are executed before 
> transferring control. For example, if serial settings have been tweaked by 
> GRUB, they should be reverted to the original state. At least, this is 
> considered to be a good manner. Another example is video settings. Let's say, 
> GRUB changes video mode to show a fancy menu. Some operating systems may not 
> work well in graphical mode, then GRUB must turn it back to text mode.

I remember about the video mode issue, but IIRC it only affects i386-pc.  Also,
I don't think anyone will assume serial port to be in a particular state during
boot.  Do we have similar concerns on ieee1275 ?

Anyway, any suggestions on how we can archieve this?  Unless I missed
something, the ieee1275/multiboot2 loader puts the OS image at its link
address, whatever it may be, which leaves us with no provisions in case it
overwrote something.

It's unlikely that it overwrites our boot routine, but when we try to unload
all modules, things break.

Makes it sound like we'll have to:

  - add a relocator in our final jump routine
  - put OS image in dynamic memory
  - put the relocator/final routine in dynamic memory
  - unload all modules
  - jump to the relocator/final routine, passing it the parameters indicating
    it has to copy OS image from dynamic memory to the target area, whichever
    it may be.

(in both cases of dynamic alloc, ensuring they won't overlap with target OS
load area)

Is this _really_ the only way to solve this problem?

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

Re: grub_dl_unload_all()

[Marco Gerards]

Robert Millan <rmh@aybabtu.com> writes:

> On Thu, Jan 24, 2008 at 09:57:45AM +0100, Yoshinori K. Okuji wrote:
>> > How important is it to unload all modules?  What do you suggest?  Do we fix
>> > everything to unload all modules (is that even possible?)?  Do we unload
>> > all modules on i386-pc "because we can" and not do this on ieee1275
>> > platforms?
>> 
>> It is important so that we can make sure that all cleanups are executed before 
>> transferring control. For example, if serial settings have been tweaked by 
>> GRUB, they should be reverted to the original state. At least, this is 
>> considered to be a good manner. Another example is video settings. Let's say, 
>> GRUB changes video mode to show a fancy menu. Some operating systems may not 
>> work well in graphical mode, then GRUB must turn it back to text mode.
>
> I remember about the video mode issue, but IIRC it only affects i386-pc.  Also,
> I don't think anyone will assume serial port to be in a particular state during
> boot.  Do we have similar concerns on ieee1275 ?

If a video driver is used, yes.  Also if memory is claimed, it has to
be released when "chainloading".

Besides that, there are many scenarios where something has to be
restored.  Especially when drivers are involved.  If you switch
scancode sets for keyboards (do you?), changing the IDT, perhaps for
the ATA driver this will become required?  It's a good mechanism to
have.

Why is this a problem?  If this is a problem for a specific module, it
should grab a reference I assume.

> Anyway, any suggestions on how we can archieve this?  Unless I missed
> something, the ieee1275/multiboot2 loader puts the OS image at its link
> address, whatever it may be, which leaves us with no provisions in case it
> overwrote something.
>
> It's unlikely that it overwrites our boot routine, but when we try to unload
> all modules, things break.

Hollis encountered this problem as well, for the MacOS loader.

> Makes it sound like we'll have to:
>
>   - add a relocator in our final jump routine
>   - put OS image in dynamic memory
>   - put the relocator/final routine in dynamic memory
>   - unload all modules
>   - jump to the relocator/final routine, passing it the parameters indicating
>     it has to copy OS image from dynamic memory to the target area, whichever
>     it may be.

This has to be implemented, no way around this.  Hollis played with
this approach, you might want to contact him.

> (in both cases of dynamic alloc, ensuring they won't overlap with target OS
> load area)
>
> Is this _really_ the only way to solve this problem?

I really think so.  It's generic, clean and guaranteed to work.

--
Marco

Re: grub_dl_unload_all()

[Robert Millan]

On Thu, Jan 24, 2008 at 12:59:44PM +0100, Marco Gerards wrote:
> >
> > I remember about the video mode issue, but IIRC it only affects i386-pc.  Also,
> > I don't think anyone will assume serial port to be in a particular state during
> > boot.  Do we have similar concerns on ieee1275 ?
> 
> If a video driver is used, yes.

grub_ofconsole_fini does nothing, except unregistering the driver in kernel.

> Also if memory is claimed, it has to
> be released when "chainloading".

It may be so, but unloading modules doesn't release the memory we claimed
in grub_machine_init (AFAICS).

> Besides that, there are many scenarios where something has to be
> restored.  Especially when drivers are involved.  If you switch
> scancode sets for keyboards (do you?),

I do, but then again this doesn't affect anyone in practice (there's a
chance it could affect OFW when running "exit", although that's not the
case, "exit" is not so important, and it is broken on XO for other reasons
anyway).

> changing the IDT, perhaps for
> the ATA driver this will become required?

No ATA driver here (yet).

> It's a good mechanism to
> have.

Yes, I agree it is good to have, but what is the current status?  Is there a
real risk that loading OS image overwrites our boot routine?  If not, I'd
rather just mimic what powerpc is doing untill proper relocation can be
implemented.

Actually, if the risk is minimal, I'd mimic what powerpc is doing anyway,
since it'll take a while to implement this, and the i386-ieee1275 remains
broken because of it.

> > Makes it sound like we'll have to:
> >
> >   - add a relocator in our final jump routine
> >   - put OS image in dynamic memory
> >   - put the relocator/final routine in dynamic memory
> >   - unload all modules
> >   - jump to the relocator/final routine, passing it the parameters indicating
> >     it has to copy OS image from dynamic memory to the target area, whichever
> >     it may be.
> 
> This has to be implemented, no way around this.  Hollis played with
> this approach, you might want to contact him.

I had preliminar (working!) code to implement this, but it's a hack.  We really
need to think this over first, as it might imply some redesign of the memory
manager, etc.

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

Re: grub_dl_unload_all()

[Robert Millan]

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

On Thu, Jan 24, 2008 at 01:26:47PM +0100, Robert Millan wrote:
> 
> I had preliminar (working!) code to implement this, but it's a hack.  We really
> need to think this over first, as it might imply some redesign of the memory
> manager, etc.

In the meantime what do you think of doing the same powerpc does?

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

[-- Attachment #2: module_unload.diff --]
[-- Type: text/x-diff, Size: 1055 bytes --]


	* kern/i386/loader.S (grub_multiboot2_real_boot)
	[GRUB_MACHINE_IEEE1275]: Copy `grub_ieee1275_entry_fn' handler to %edx.
	Avoid calling grub_dl_unload_all() or grub_stop_floppy(), since
	grub_dl_unload_all() is not usable at this point.

diff -ur grub2/kern/i386/loader.S tmp/kern/i386/loader.S
--- grub2/kern/i386/loader.S	2008-01-05 13:14:05.000000000 +0100
+++ tmp/kern/i386/loader.S	2008-01-23 21:12:14.000000000 +0100
@@ -16,6 +16,7 @@
  *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <grub/machine/machine.h>
 
 /*
  * Note: These functions defined in this file may be called from C.
@@ -151,9 +152,13 @@
         /* Move the address of the multiboot information structure to ebx.  */
         movl    %edx,%ebx
 
+#ifdef GRUB_MACHINE_IEEE1275
+	movl EXT_C(grub_ieee1275_entry_fn), %edx
+#else
         /* Unload all modules and stop the floppy driver.  */
         call    EXT_C(grub_dl_unload_all)
         call    EXT_C(grub_stop_floppy)
+#endif
 
         /* Interrupts should be disabled.  */
         cli