grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Which partitioning schemes should be supported by GRUB?


From: Grégoire Sutre
Subject: Re: Which partitioning schemes should be supported by GRUB?
Date: Tue, 15 Jun 2010 23:07:42 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]