Re: for ppc, include all modules in the core image

[Andrey Borzenkov]

В Mon, 22 Oct 2012 19:53:17 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> пишет:

> On 22.10.2012 19:30, Paulo Flabiano Smorigo/Brazil/IBM wrote:
> 
> > 
> > Quoting Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
> > 
> >> On 16.10.2012 12:28, Paulo Flabiano Smorigo/Brazil/IBM wrote:
> >>
> >>> Hi all!
> >>>
> >>> This patch implements the solution suggested by Gustavo Luiz Duarte
> >>> <address@hidden>:
> >>>
> >>> Adding more modules to be built-in to the grub core ELF is easy. It is a
> >>> parameter passed by grub2-install to grub2-mkimage. However, there is a
> >>> downside
> >>> on adding many modules to the core ELF: they are fully initialized in
> >>> the grub's
> >>> first stage. It means you could hit a bug on a module you don't need and
> >>> end up
> >>> with a non-bootable system.
> >>>
> >>> Another downside is that you wouldn't get updates for these built-in
> >>> modules, as
> >>> updating the grub2 package only updates the modules residing in /boot
> >>> and not
> >>> the grub core ELF in the PReP partition.
> >>>
> >>> A proper solution would be to add to grub the ability of having built-in
> >>> *inactive* modules which would be loaded and initialized only on demand
> >>> (i.e.
> >>> explicitly calling the insmod command).
> >>>
> >>
> >> This is what memdisk does (i.a.). Why do you need anything else?
> >>
> >>>
> >>>
> >>> _______________________________________________
> >>> Grub-devel mailing list
> >>> address@hidden
> >>> https://lists.gnu.org/mailman/listinfo/grub-devel
> >>
> >>
> >>
> >> -- 
> >> Regards
> >> Vladimir 'φ-coder/phcoder' Serbinenko
> > 
> > Hi phcoder,
> > 
> > Thanks for the reply. I studied memdisk and tried to use grub-mkstandalone
> > but the idea used in this patch is different. It's like a plan B just in
> > case /boot isn't found. It gives the "grub rescue" a new level of recovery,
> > increasing the chances to fix the system. This extra modules is stored in a
> > different area and will *only* be used in this case.
> > 
> > Otherwise, the normal modules, inside /boot, will be used normally and If
> > there is an update or if grub.cfg changes, the new files will be used.
> > 
> 
> Can't you attain the same result with memdisk but not pointing root to it?
> This part is size-critical and we need a good reason to put new features.
> 

The problem is, currently there is no way to separate module location
and the rest (grub.cfg to start with). Both are searched for under
$prefix. So while you can embed memory disk that contains all modules,
you cannot tell grub to autoload modules from there while continuing
to use /boot/grub for everything else. 

Separate $module_prefix would be useful here. As the minimal step, use
$module_prefix for module loading and initialize it to $prefix by
default (at the same time as $prefix is computed). Then users can point
$module_prefix to memory disk later, in grub.cfg.

Will you accept the patch? It looks trivial enough. It does increase
size of kernel though, so I would be interested if RH guys would
consider using this solution?

signature.asc
Description: PGP signature