Re: grub_dl_unload_all()

[Marco Gerards]

Robert Millan <address@hidden> 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