Re: Which partitioning schemes should be supported by GRUB?

["Grégoire Sutre" <gregoire.sutre@gmail.com>]

On 06/15/2010 01:21 PM, Colin Watson wrote:

>> A possible solution would be to use the multiboot-command line.  AFAIK,
>> the boot_device field of the multiboot information structure is supposed
>> to pass this kind of partition information, but you cannot specify the
>> partmaps in this field, hence its interpretation is ambiguous.
>
> That would potentially allow a user to override things, but doesn't help
> with users who don't change their configuration.  Unless the user
> explicitly configures things, boot_device is all we've got.

Ok.

> Thus, I guess we end up with a two-part fix:
>
>    1) Honour key=value pairs in the multiboot command line when booting
>       GRUB itself as a multiboot image.  These would simply become
>       environment variables.

This would be nice.

>    2) If multiboot_trampoline needs to change install_dos_part or
>       install_bsd_part based on the value of boot_device in the MBI, then
>       we know that the drive/partition part of prefix (which was
>       calculated in the same way as install_dos_part and install_bsd_part
>       when grub-setup was run) is now invalid and should be ignored.
>       This fact needs to be passed on to make_install_device.

Since the command-line processing of the MBI is done after startup.S (in 
grub_machine_init()),

- the MBI (only the relevant portions for simplicity) needs to be copied
   to a safe place.  The patch does it at the end of grub_machine_init(),
   but I'm afraid this might be too late: the MBI may have been
   overwritten before we reach that point.  Or is the code (startup.S and
   grub_machine_init()) designed to guarantee that all memory writes are
   in safe locations, outside of the whole MBI?

- couldn't the complete processing of the MBI be performed in the same
   place, i.e. grub_machine_init()?  The assembly multiboot part would
   only check whether GRUB was booted by multiboot, and set (or copy)
   the MBI in that case.  Then the procedure to set grub_prefix would be
   coded in one place.  This would require though, for multiboot, to get
   grub_boot_drive from the boot_device field (the current assembly code
   takes care of this).

>   void
>   grub_machine_init (void)
>   {
> @@ -214,6 +279,15 @@ grub_machine_init (void)
>     if (! grub_os_area_addr)
>       grub_fatal ("no upper memory");
>
> +  if (startup_multiboot_info)
> +    {
> +      /* Move MBI to a safe place.  */
> +      grub_memmove (&kern_multiboot_info, startup_multiboot_info,
> +		    sizeof (struct multiboot_info));

Moving the MBI is more complex, since the structure contains pointers
to other structures (themselves containing pointers etc.).  But in our
case it's not too painful since we only need to copy the struct
multiboot_info and the string pointed to by its cmdline field (and set
the field to the new address).

Grégoire