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: Tue, 23 Sep 2014 21:43:53 -0700 [thread overview]
Message-ID: <CAFECyb9dBHpnM8-0ej7KjEE_7yRDDtwLwYRfQCTsyvMuAJNPOw@mail.gmail.com> (raw)
In-Reply-To: <CAFECyb_ELv7u4BzpqA_CHZ5rGSgjOVyPFn2FdT9yWNKZENxHhw@mail.gmail.com>
On Tue, Sep 23, 2014 at 6:23 PM, Roy Franz <roy.franz@linaro.org> wrote:
> On Mon, Sep 22, 2014 at 6:57 PM, Roy Franz <roy.franz@linaro.org> wrote:
>> 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.
>>
> OK, I looked at this a little more, and the original code would take
> anything after the ucode filename
> and put it into the mbi.string field for the ucode module. All the
> modules where treated the same in this
> regard - they could all have options.
>
> If ucode never has options, I can remove this, but this would be a
> change in behavior.
The EFI config file documentation specifies just the filename, so I
have simplified this
in the next version.
>
>
>>>
>>>> @@ -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
next prev parent reply other threads:[~2014-09-24 4:43 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
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 [this message]
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=CAFECyb9dBHpnM8-0ej7KjEE_7yRDDtwLwYRfQCTsyvMuAJNPOw@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).