Re: [PATCH] Scan root device dynamically at startup

[Bean]

On Thu, May 29, 2008 at 5:58 PM, Robert Millan <address@hidden> wrote:
> On Wed, May 28, 2008 at 10:53:07PM +0800, Bean wrote:
>>
>> In function grub_set_root_dev (main.c), it uses prefix to calculated
>> root, so setting prefix is sufficient.
>>
>> About the name, well, findprefix works for me too.
>>
>> > Also, what this module is doing looks very similar to "search --set".  Did
>> > you check if search command can be used for what you want?  (or otherwise
>> > adapted)
>>
>> The findroot module is used to locate normal.mod. But search is a
>> command, it can only be used after normal.mod has been loaded.
>
> I've been thinking a bit more about this, and my impression is that it the
> approach is quite ad-hoc.  For example, some similar problems that this
> solution wouldn't solve, but that a very similar solution would:
>
>  a- normal.mod was built into grub.elf (perhaps because the firmware can load
>    big files).  Then the problem is finding grub.cfg instead of normal.mod.

If the firmware support large image file, then it's no problem. For
image ~ 64K, we can include normal and some basic command. But for
image ~ 32K (like vista boot loader), it can only contain kernel and
one of the file system driver.

>
>  b- User has a disk liing around which happens to have a normal.mod from
>    an earlier version of grub (let's assume different ABI).  Turns out this
>    disk is used for something else and can't be supressed.  A solution could
>    be to use UUIDs for the search, but that can't always work since we need
>    a "smart" install process that can probe for them (unlike in the situation
>    you described -- I can't imagine doing fancy stuff in bare-bones Vista).
>

I think this is the most convenient way of installing grub2 in vista.
User don't need any customization. They just add the entry and copy
/boot/grub to any supported partition. Besides, our driver currently
don't support UUID, and some partition doesn't have UUID (like FAT).

>  c- Search for normal.mod was ok, but then this particular port of grub can't
>    accept the prefix variable from your module, because it already got this
>    variable from the firmware (OFW does this).  And the variable from firmware
>    happens to be completely unusable.

The module initialization code is run in grub_load_modules (), It's
before the platform code  grub_machine_set_prefix (). If findroot has
find the prefix, it won't use the firmware value anymore.

> I think a solution that would fit well here is to use memdisk to embed a
> grub.cfg.  Then in each situation we could have a different grub.cfg script
> that finds appropiate prefix using the search command.

memdisk is not so useful in such situation. grub.cfg need normal.mod
for its script engine. So we need to embed normal.mod. and at least
search.mod. Such image is well above 32K limit.

-- 
Bean