grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH 4/5] arm64: Add multiboot support file
Date: Thu, 07 May 2015 15:40:34 +0200	[thread overview]
Message-ID: <554B6B52.6040602@gmail.com> (raw)
In-Reply-To: <54931912.1050804@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 9555 bytes --]

On 18.12.2014 19:12, Fu Wei wrote:
>   grub-core/loader/arm64/multiboot.c
>   include/grub/arm64/multiboot.h
> 
> Add commands register code and hearder file into 
> grub-core/loader/arm64/linux.c
> 
>   - This multiboot support is built into linux module for aarch64.
> 
>   - The implementation for Xen is following  <Multiboot on ARM Specification>:
>     http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
>     and xen/docs/misc/arm/device-tree/booting.txt in Xen source code.
> 
>   - This adds support for the Xen Multiboot on ARM specification for arm64,
>     enabling config file portability across the architectures.
> 
>   - The multiboot command is currently x86-only, so reusing these command names
>     should not conflict with any future additions of ARM support to multiboot2.
> 
>   - The reason of adding this functionality to the existing "linux" module
>     rather than "multiboot(2)"
>     (1)multiboot is x86 only
multiboot2 isn't. But what you implement here is not multiboot. It's
xen-specific protocol. So it should be called xen_hypervisor and
xen_module. It's ok to add xen_hypervisor as an alias to multiboot on x86
>     (2)Multiboot is added to "linux" module because it reuses existing code.
> 
Not a reason. You can move the code you reuse to separate module.

> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
> index 42443bc..b963a62 100644
> --- a/grub-core/Makefile.core.def
> +++ b/grub-core/Makefile.core.def
> @@ -1673,6 +1673,7 @@ module = {
>    ia64_efi = loader/ia64/efi/linux.c;
>    arm = loader/arm/linux.c;
>    arm64 = loader/arm64/linux.c;
> +  arm64 = loader/arm64/multiboot.c;
Ditto
> +
> +  grub_arm64_linux_register_multiboot_command (mod);
> +
Ditto
>    my_mod = mod;
>  }
>  
> @@ -478,4 +482,6 @@ GRUB_MOD_FINI (linux)
>    grub_unregister_command (cmd_linux);
>    grub_unregister_command (cmd_initrd);
>    grub_unregister_command (cmd_devicetree);
> +
> +  grub_arm64_linux_unregister_multiboot_command ();
Ditto

> +static grub_dl_t linux_mod;
> +static int loaded;
> +
> +static struct multiboot_binary *multiboot_kernel = NULL;
> +static struct multiboot_binary *module_head = NULL;
> +static const grub_size_t module_default_align[] = {
> +  MODULE_IMAGE_MIN_ALIGN,
> +  MODULE_INITRD_MIN_ALIGN,
> +  MODULE_OTHER_MIN_ALIGN,
> +  MODULE_CUSTOM_MIN_ALIGN
> +};
> +
> +static void *multiboot_fdt = NULL;
> +static const compat_string_struct_t default_compat_string[] = {
> +  FDT_COMPATIBLE (MODULE_IMAGE_COMPATIBLE),
> +  FDT_COMPATIBLE (MODULE_INITRD_COMPATIBLE),
> +  FDT_COMPATIBLE (MODULE_OTHER_COMPATIBLE)
> +};
> +
> +static grub_err_t
> +set_module_type (struct multiboot_binary *module,
> +                 int argc, char *argv[], int *file_name_index)
> +{
> +  static module_type_t default_type = MODULE_IMAGE;
> +  char *temp = NULL;
> +  grub_size_t total_size = 0;
> +  int num_types = 0, i;
> +  char **compat_string_temp_array =
> +    (char **) grub_zalloc (sizeof (char *) * argc);
> +
> +  *file_name_index = 0;
> +
> +  /* if there are some options we need to process. */
> +  if (argc >= 3)
> +    {
> +      while (argc > 1)
> +	{
> +	  if (grub_strcmp (argv[0], "--type") == 0)
> +	    {
Can we have separate xen_* commands for different types? It's ok for
them to call similar code paths under the hood
> +	      module->node_info.type = MODULE_CUSTOM;
> +	      ARG_SHIFT(argc, argv);
> +	      total_size += grub_strlen (argv[0]) + 1;
> +	      compat_string_temp_array[num_types++] = argv[0];
> +	      ARG_SHIFT(argc, argv);
> +	      (*file_name_index) += 2;
> +	    }
> +	  else
> +	    /* we can add more options process code here. */
> +	    break;
> +	}
> +    }
> +
> +  /* For the default module type :
> +   * The implementation is following <Multiboot on ARM Specification>:
Could this thing be renamed to "xen ARM boot protocol"?

> +  if (module->node_info.type != MODULE_CUSTOM)
> +    {
> +      /* the module type is set by the load order */
> +      module->node_info.type = default_type;
> +      switch (default_type)
> +        {
> +        case MODULE_IMAGE:
> +          default_type = MODULE_INITRD;
> +          break;
> +
> +        case MODULE_INITRD:
> +          default_type = MODULE_OTHER;
> +          break;
> +
> +        case MODULE_OTHER:
> +          break;
> +
> +        default:
> +          default_type = MODULE_IMAGE; /* error, reset the type */
> +          return (grub_error (GRUB_ERR_BAD_ARGUMENT, N_("invalid argument")));
> +        }
> +    }
> +  else
> +    {
> +      /* the module type is set by "--type"(MODULE_CUSTOM) */
> +      module->node_info.compat_string = temp =
> +	  (char *) grub_zalloc (total_size);
> +      module->node_info.compat_string_size = total_size;
> +      for (i = 0; num_types > 0; num_types--, i++, temp++)
> +	{
> +	  grub_strcpy (temp, compat_string_temp_array[i]);
> +	  temp += grub_strlen (compat_string_temp_array[i]);
> +	}
> +    }
> +
Unnecessarry complexity just to have less commands. We've been down this
path with grub1, it's not good.
> +  grub_free (compat_string_temp_array);
> +  return (GRUB_ERR_NONE);
> +}
> +
> +static grub_err_t
> +prepare_kernel_params (void)
> +{
> +  int retval;
> +  int chosen_node = 0;
> +
> +  multiboot_fdt = grub_linux_get_fdt ();
> +  if (!multiboot_fdt)
> +    return (grub_error (GRUB_ERR_BAD_OS, "failed to install/update FDT"));
> +
> +  chosen_node = grub_fdt_find_subnode (multiboot_fdt, 0, "chosen");
> +  if (chosen_node < 0)
> +    chosen_node = grub_fdt_add_subnode (multiboot_fdt, 0, "chosen");
> +  if (chosen_node < 1)
> +    return (grub_error (GRUB_ERR_BAD_OS, "failed to install/update FDT"));
> +
> +  grub_dprintf ("multiboot_loader",
> +		"Multiboot Kernel cmdline : %s @ %p size:%d\n",
> +		multiboot_kernel->cmdline, multiboot_kernel->cmdline,
> +		multiboot_kernel->cmdline_size);
> +
> +  retval = grub_fdt_set_prop (multiboot_fdt, chosen_node, "bootargs",
> +                              multiboot_kernel->cmdline,
> +                              multiboot_kernel->cmdline_size);
> +  if (retval)
> +    return grub_error (GRUB_ERR_BAD_OS, "failed to install/update FDT");
> +
> +  return (GRUB_ERR_NONE);
> +}
> +
> +static grub_err_t
> +prepare_module_params (struct multiboot_binary *module)
> +{
> +  int retval, chosen_node = 0, module_node = 0;
> +  char module_name[FDT_NODE_NAME_MAX_SIZE];
> +
> +  retval = grub_snprintf (module_name, FDT_NODE_NAME_MAX_SIZE,
> +			  "module@%lx",
> +			  multiboot_address_align (module->start,
> +						   module->align));
> +  grub_dprintf ("multiboot_loader", "Module node name %s \n", module_name);
> +
> +  if (retval < (int) sizeof ("module@"))
> +    return (grub_error (GRUB_ERR_BAD_OS,
> +			N_("failed to install/update FDT")));
> +
What kind of errors do you expect here? I don't see grub_snprintf
erroring here at all under any circumstances.

Please make errors more descriptive. You have same error message for at
least 5 different problems.
Is this error likely to happen to a normal user? If not, let's not load
translators with obscure technical strings. If it is likely it must way
more clearer and have TRANSLATORS comment on context.
> +  chosen_node = grub_fdt_find_subnode (multiboot_fdt, 0, "chosen");
> +  if (chosen_node < 0)
> +    chosen_node = grub_fdt_add_subnode (multiboot_fdt, 0, "chosen");
> +  if (chosen_node < 1)
> +    return (grub_error (GRUB_ERR_BAD_OS, "failed to install/update FDT"));
> +
> +  module_node =
> +    grub_fdt_find_subnode (multiboot_fdt, chosen_node, module_name);
> +  if (module_node < 0)
> +    module_node =
> +      grub_fdt_add_subnode (multiboot_fdt, chosen_node, module_name);
> +
Could you please encapsulate find/add/setprop to a separate function?
> +  retval = grub_fdt_set_prop (multiboot_fdt, module_node, "compatible",
> +			      module->node_info.compat_string,
> +			      (grub_uint32_t) module->node_info.compat_string_size);
> +  if (retval)
> +    return (grub_error (GRUB_ERR_BAD_OS,
> +			N_("failed to install/update FDT")));
> +
Style here and in many other places: no parens for return.
> +static grub_err_t
> +multiboot_binary_load (struct multiboot_binary *binary, grub_file_t file,
> +		       int argc, char *argv[])
> +{
> +  binary->size = grub_file_size (file);
> +  grub_dprintf ("multiboot_loader", "Multiboot %s file size: 0x%lx\n",
> +		binary->name, binary->size);
> +
> +  binary->start = (grub_addr_t) grub_efi_allocate_pages (0,
> +							 (BYTES_TO_PAGES
> +							  (binary->size +
> +							   binary->align)));
> +  if (!binary->start)
> +    return (grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory")));
> +
> +  grub_dprintf ("multiboot_loader", "Multiboot %s numpages: 0x%lx\n",
> +		binary->name, BYTES_TO_PAGES (binary->size + binary->align));
> +
> +  if (grub_file_read (file,
> +		      (void *) multiboot_address_align (binary->start,
> +							binary->align),
> +		      binary->size) < (grub_ssize_t) binary->size)
> +    {
> +      single_binary_unload (binary);
> +      return (grub_error (GRUB_ERR_BAD_OS,
> +			  N_("premature end of file %s"), argv[0]));
Please don't override grub_errno if it's already set. See other loader
for example.
> --- /dev/null
> +++ b/include/grub/arm64/multiboot.h
Again, please don't call it multiboot


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

      reply	other threads:[~2015-05-07 13:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-18 18:12 [PATCH 4/5] arm64: Add multiboot support file Fu Wei
2015-05-07 13:40 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=554B6B52.6040602@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).