xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Roy Franz <roy.franz@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: keir <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	tim <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Fu Wei <fu.wei@linaro.org>
Subject: Re: [PATCH V5 10/15] Add arch specific module handling to read_file()
Date: Mon, 22 Sep 2014 18:57:41 -0700	[thread overview]
Message-ID: <CAFECyb9DhtaUyhaMAm9Jsz+5SWW=DUCfwcBr5WsyRSwY6u1e-A@mail.gmail.com> (raw)
In-Reply-To: <542035B20200007800036ED3@mail.emea.novell.com>

On Mon, Sep 22, 2014 at 5:44 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 19.09.14 at 00:50, <roy.franz@linaro.org> wrote:
>> --- a/xen/common/efi/boot.c
>> +++ b/xen/common/efi/boot.c
>> @@ -56,12 +56,13 @@ static void noreturn blexit(const CHAR16 *str);
>>  static void PrintErrMesg(const CHAR16 *mesg, EFI_STATUS ErrCode);
>>  static char *get_value(const struct file *cfg, const char *section,
>>                                const char *item);
>> -static void  split_value(char *s);
>> +static char *split_string(char *s);
>>  static CHAR16 *s2w(union string *str);
>>  static char *w2s(const union string *str);
>> -static bool_t  read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
>> -                               struct file *file);
>> +static size_t wstrlen(const CHAR16 * s);
>>  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
>> +static bool_t read_file(EFI_FILE_HANDLE dir_handle, struct file *file,
>> +                               CHAR16 *filename, char *options);
>
> Please don't needlessly move this declaration down.
>
I'll fix this.

>> @@ -115,6 +116,15 @@ static void __init DisplayUint(UINT64 Val, INTN Width)
>>      PrintStr(PrintString);
>>  }
>>
>> +static size_t __init wstrlen(const CHAR16 * s)
>> +{
>> +     const CHAR16 *sc;
>> +
>> +     for (sc = s; *sc != L'\0'; ++sc)
>> +             /* nothing */;
>> +     return sc - s;
>> +}
>
> Coding style (many issues).

static size_t __init wstrlen(const CHAR16 *s)
{
     const CHAR16 *sc;

     for ( sc = s; *sc != L'\0'; ++sc )
            ;
     return sc - s;
}

Is the above OK?  Not sure what else to change here...

>
>> @@ -404,18 +414,33 @@ static CHAR16 *__init point_tail(CHAR16 *fn)
>>              break;
>>          }
>>  }
>> +/*
>> + * Truncate string at first space, and return pointer
>> + * to remainder of string.
>
> ... (if any).
>

Sure.


>> + */
>> +static char * __init split_string(char *s)
>> +{
>> +    while ( *s && !isspace(*s) )
>> +        ++s;
>> +    if ( *s )
>> +    {
>> +        *s = 0;
>> +        return(s + 1);
>
> No parentheses here please.

sure


>
>> +    }
>> +    return NULL;
>> +}
>>
>> -static bool_t __init read_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
>> -                               struct file *file)
>> +static bool_t __init read_file(EFI_FILE_HANDLE dir_handle, struct file *file,
>> +                               CHAR16 *filename, char *options)
>
> Is the renaming from "name" to "filename" really necessary/useful?
> And the flipping of the order of pre-existing parameters?

I'll fix this.

>
>> @@ -659,18 +678,19 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
>> *SystemTable)
>>      EFI_LOADED_IMAGE *loaded_image;
>>      EFI_STATUS status;
>>      unsigned int i, argc;
>> -    CHAR16 **argv, *file_name, *cfg_file_name = NULL, *options = NULL;
>> +    CHAR16 **argv, *options = NULL;
>>      UINTN cols, rows, depth, size, info_size, gop_mode = ~0;
>>      EFI_HANDLE *handles = NULL;
>>      EFI_SHIM_LOCK_PROTOCOL *shim_lock;
>>      EFI_GRAPHICS_OUTPUT_PROTOCOL *gop = NULL;
>>      EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *mode_info;
>>      EFI_FILE_HANDLE dir_handle;
>> -    union string section = { NULL }, name;
>> +    union string section = { NULL }, name, file_name, cfg_file_name = {NULL};
>
> Your addition should be consistent with existing code (blanks around
> NULL). But - why are you changing the types of the two variables in
> the first place? Afaics all references to them now are using the .w
> member access, suggesting that this is just a remnant of your earlier
> version changes.
>

Yes, this is leftover type changes from a previous version.   Both
these should be able to to be
reverted to simple CHAR16 *
>> @@ -274,8 +275,8 @@ static void __init efi_arch_cfg_file_late(EFI_FILE_HANDLE dir_handle, char *sect
>>      if ( name.s )
>>      {
>>          microcode_set_module(mbi.mods_count);
>> -        split_value(name.s);
>> -        read_file(dir_handle, s2w(&name), &ucode);
>> +        options = split_string(name.s);
>> +        read_file(dir_handle, &ucode, s2w(&name), options);
>
> Perhaps rather NULL instead of options?

Yup.

>
>> @@ -575,3 +576,30 @@ static void __init efi_arch_memory(void)
>>      l3_bootmap[l3_table_offset(xen_phys_start + (8 << L2_PAGETABLE_SHIFT) - 1)] =
>>          l3e_from_paddr((UINTN)l2_bootmap, __PAGE_HYPERVISOR);
>>  }
>> +
>> +static void __init efi_arch_handle_module(struct file *file, const CHAR16 *name,
>> +                                          char *options)
>> +{
>> +    union string local_name;
>> +    void *ptr;
>> +
>> +    /*
>> +     * Make a copy, as conversion is destructive, and caller still wants
>> +     * wide string available after this call returns.
>> +     */
>> +    if ( efi_bs->AllocatePool(EfiLoaderData, (wstrlen(name) + 1) * sizeof(*name),
>> +                              &ptr) != EFI_SUCCESS )
>> +        blexit(L"ERROR Unable to allocate string buffer\r\n");
>
> Iirc I said this before, but just in case: No explicit newline on strings
> passed to blexit() please.
Yes.
>
> Jan

  reply	other threads:[~2014-09-23  1:57 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18 22:49 [PATCH V5 00/15] arm64 EFI stub Roy Franz
2014-09-18 22:49 ` [PATCH V5 01/15] move x86 EFI boot/runtime code to common/efi Roy Franz
2014-09-19  8:49   ` Jan Beulich
2014-09-22 10:51     ` Ian Campbell
2014-09-18 22:49 ` [PATCH V5 02/15] Move x86 specific funtions/variables to arch header Roy Franz
2014-09-19  8:37   ` Jan Beulich
2014-09-22 10:52     ` Ian Campbell
2014-09-22 10:56       ` Jan Beulich
2014-09-22 11:09         ` Ian Campbell
2014-09-22 11:31           ` Jan Beulich
2014-09-22 12:54   ` Jan Beulich
2014-09-23  2:08     ` Roy Franz
2014-09-23 12:24       ` Jan Beulich
2014-09-24  2:35         ` Roy Franz
2014-09-24  8:12           ` Jan Beulich
2014-09-18 22:49 ` [PATCH V5 03/15] create arch functions to allocate memory for and process EFI memory map Roy Franz
2014-09-19  8:47   ` Jan Beulich
2014-09-23  1:14     ` Roy Franz
2014-09-18 22:49 ` [PATCH V5 04/15] Add architecture functions for pre/post ExitBootServices Roy Franz
2014-09-22 12:11   ` Jan Beulich
2014-09-18 22:49 ` [PATCH V5 05/15] Add efi_arch_cfg_file_early/late() to handle arch specific cfg file fields Roy Franz
2014-09-22 12:13   ` Jan Beulich
2014-09-18 22:49 ` [PATCH V5 06/15] Add efi_arch_handle_cmdline() for processing commandline Roy Franz
2014-09-22 12:17   ` Jan Beulich
2014-09-23  1:40     ` Roy Franz
2014-09-23 12:25       ` Jan Beulich
2014-09-24  0:09         ` Roy Franz
2014-09-24  8:13           ` Jan Beulich
2014-09-24  9:33             ` Ian Campbell
2014-09-24 11:34               ` Jan Beulich
2014-09-18 22:49 ` [PATCH V5 07/15] Move x86 specific disk probing code Roy Franz
2014-09-22 12:20   ` Jan Beulich
2014-09-23  1:44     ` Roy Franz
2014-09-18 22:49 ` [PATCH V5 08/15] Create arch functions for console and video init Roy Franz
2014-09-22 12:21   ` Jan Beulich
2014-09-18 22:50 ` [PATCH V5 09/15] Add efi_arch_memory() for arch specific memory setup Roy Franz
2014-09-22 12:24   ` Jan Beulich
2014-09-23  1:45     ` Roy Franz
2014-09-18 22:50 ` [PATCH V5 10/15] Add arch specific module handling to read_file() Roy Franz
2014-09-22 12:44   ` Jan Beulich
2014-09-23  1:57     ` Roy Franz [this message]
2014-09-23 12:28       ` Jan Beulich
2014-09-23 12:41         ` Ian Campbell
2014-09-23 12:55           ` Jan Beulich
2014-09-24  1:23       ` Roy Franz
2014-09-24  4:43         ` Roy Franz
2014-09-24  8:18         ` Jan Beulich
2014-09-18 22:50 ` [PATCH V5 11/15] Add several misc. arch functions for EFI boot code Roy Franz
2014-09-22 12:45   ` Jan Beulich
2014-09-18 22:50 ` [PATCH V5 12/15] Add efi_arch_use_config_file() function to control use of config file Roy Franz
2014-09-22 12:48   ` Jan Beulich
2014-09-23  1:59     ` Roy Franz
2014-09-18 22:50 ` [PATCH V5 13/15] add arm64 cache flushing code from linux v3.16 Roy Franz
2014-09-22 10:54   ` Ian Campbell
2014-09-22 23:42     ` Roy Franz
2014-09-23  7:42       ` Ian Campbell
2014-09-18 22:50 ` [PATCH V5 14/15] Update libfdt to v1.4.0 Roy Franz
2014-09-22 11:20   ` Ian Campbell
2014-09-22 23:57     ` Roy Franz
2014-09-23  7:43       ` Ian Campbell
2014-09-18 22:50 ` [PATCH V5 15/15] Add ARM EFI boot support Roy Franz
2014-09-22 11:20   ` Ian Campbell
2014-09-22 23:50     ` Roy Franz

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='CAFECyb9DhtaUyhaMAm9Jsz+5SWW=DUCfwcBr5WsyRSwY6u1e-A@mail.gmail.com' \
    --to=roy.franz@linaro.org \
    --cc=JBeulich@suse.com \
    --cc=fu.wei@linaro.org \
    --cc=ian.campbell@citrix.com \
    --cc=keir@xen.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.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).