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>,
linaro-uefi <linaro-uefi@lists.linaro.org>,
Fu Wei <fu.wei@linaro.org>
Subject: Re: [PATCH V2 05/12] replace split_value() with truncate_string()
Date: Wed, 6 Aug 2014 15:37:37 -0700 [thread overview]
Message-ID: <CAFECyb-0xBht9mdgZe2ohmMF3UheT1hnV3bkaACA+VtON7MVZg@mail.gmail.com> (raw)
In-Reply-To: <53D0CFAD02000078000255F2@mail.emea.novell.com>
On Thu, Jul 24, 2014 at 12:19 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 22.07.14 at 02:43, <roy.franz@linaro.org> wrote:
>> --- a/xen/arch/x86/efi/boot.c
>> +++ b/xen/arch/x86/efi/boot.c
>> @@ -466,7 +466,13 @@ static char *__init get_value(const struct file *cfg, const char *section,
>> break;
>> default:
>> if ( match && strncmp(ptr, item, ilen) == 0 && ptr[ilen] == '=' )
>> - return ptr + ilen + 1;
>> + {
>> + ptr += ilen + 1;
>> + /* strip off any leading spaces */
>
> Coding style.
>
>> + while ( *ptr && isspace(*ptr) )
>> + ptr++;
>> + return ptr;
>> + }
>
> It's unclear how this whole hunk is related to the patch subject.
>
>> @@ -489,14 +495,19 @@ bool_t __init load_file(EFI_FILE_HANDLE dir_handle, CHAR16 *name,
>> return 0;
>> }
>>
>> -static void __init split_value(char *s)
>> +/* Truncate string at first space, and return pointer
>> + * to remainder of string.
>> + */
>
> Coding style again.
>
>> +char * __init truncate_string(char *s)
>
> Non-static function without declaration in any header.
>
>> {
>> - while ( *s && isspace(*s) )
>> - ++s;
>> - place_string(&mb_modules[mbi.mods_count].string, s);
>> while ( *s && !isspace(*s) )
>> ++s;
>> - *s = 0;
>> + if (*s)
>> + {
>> + *s = 0;
>> + return(s + 1);
>> + }
>> + return(NULL);
>
> None of the callers uses the return value - why is the function return
> type not "void"? Also, if there is a reason, then no parentheses around
> the return expression please.
I am making these changes to make the basic functionality share-able
with the arm64
stub. The users of this function's return value come in when the arm
stub is added.
The declaration is added to efi-shared.h when it is moved - I can make
it static here until then.
I very deliberately am separating code refactoring from code movement
patches which causes
the separation between the creation of a function with a return value
that is not currently used.
>
>> @@ -893,7 +904,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
>> }
>> if ( !name.s )
>> blexit(L"No Dom0 kernel image specified.");
>> - split_value(name.s);
>> + place_string(&mb_modules[mbi.mods_count].string, name.s);
>> + truncate_string(name.s);
>> load_ok = load_file(dir_handle, s2w(&name), &kernel);
>> efi_bs->FreePool(name.w);
>> if ( !load_ok )
>> @@ -907,7 +919,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
>> name.s = get_value(&cfg, section.s, "ramdisk");
>> if ( name.s )
>> {
>> - split_value(name.s);
>> + place_string(&mb_modules[mbi.mods_count].string, name.s);
>> + truncate_string(name.s);
>> load_ok = load_file(dir_handle, s2w(&name), &ramdisk);
>> efi_bs->FreePool(name.w);
>> if ( !load_ok )
>> @@ -920,7 +933,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
>> if ( name.s )
>> {
>> microcode_set_module(mbi.mods_count);
>> - split_value(name.s);
>> + place_string(&mb_modules[mbi.mods_count].string, name.s);
>> + truncate_string(name.s);
>> load_ok = load_file(dir_handle, s2w(&name), &ucode);
>> efi_bs->FreePool(name.w);
>> if ( !load_ok )
>> @@ -930,7 +944,8 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
>> name.s = get_value(&cfg, section.s, "xsm");
>> if ( name.s )
>> {
>> - split_value(name.s);
>> + place_string(&mb_modules[mbi.mods_count].string, name.s);
>> + truncate_string(name.s);
>> load_ok = load_file(dir_handle, s2w(&name), &xsm);
>> efi_bs->FreePool(name.w);
>> if ( !load_ok )
>
> Looking at all these I wonder why you didn't retain split_value() as a
> simple wrapper.
I should be able to do that.
>
> Furthermore splitting out the place_string() doesn't seem very
> efficient, as imo the goal ought to be for efi_start() to become
> common code (or at least the module loading part of fit), i.e.
> there's no win at all from the change you're doing here.
I don't think that combining the x86 and arm efi_start() will work out
that cleanly. Arm is using device tree from getting information from
GRUB and/or the firmware, so I think you'd end up with a lot of conditional
code.
>
> Jan
>
next prev parent reply other threads:[~2014-08-06 22:37 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-22 0:43 [PATCH V2 00/12] arm64 EFI stub Roy Franz
2014-07-22 0:43 ` [PATCH V2 01/12] Create efi-shared.[ch], and move string functions Roy Franz
2014-07-23 16:31 ` Jan Beulich
2014-07-28 15:41 ` Ian Campbell
2014-07-28 15:52 ` Jan Beulich
2014-07-28 15:56 ` Ian Campbell
2014-07-28 16:00 ` Jan Beulich
2014-07-28 16:04 ` Ian Campbell
2014-07-28 16:10 ` Jan Beulich
2014-08-06 23:55 ` Roy Franz
2014-08-07 6:17 ` Jan Beulich
2014-08-09 0:27 ` Roy Franz
2014-08-06 23:42 ` Roy Franz
2014-07-22 0:43 ` [PATCH V2 02/12] rename printErrMsg to PrintErrMesgExit Roy Franz
2014-07-23 16:33 ` Jan Beulich
2014-07-22 0:43 ` [PATCH V2 03/12] Refactor get_parent_handle for sharing Roy Franz
2014-07-23 16:37 ` Jan Beulich
2014-07-22 0:43 ` [PATCH V2 04/12] Refactor read_file() so it can be shared Roy Franz
2014-07-24 7:09 ` Jan Beulich
2014-08-06 18:38 ` Roy Franz
2014-08-07 6:20 ` Jan Beulich
2014-08-07 17:26 ` Roy Franz
2014-07-22 0:43 ` [PATCH V2 05/12] replace split_value() with truncate_string() Roy Franz
2014-07-24 7:19 ` Jan Beulich
2014-08-06 22:37 ` Roy Franz [this message]
2014-08-07 6:24 ` Jan Beulich
2014-08-18 23:38 ` Roy Franz
2014-08-19 12:56 ` Jan Beulich
2014-07-22 0:43 ` [PATCH V2 06/12] add read_config_file() function for XEN EFI config file Roy Franz
2014-07-24 7:32 ` Jan Beulich
2014-08-06 22:42 ` Roy Franz
2014-07-22 0:43 ` [PATCH V2 07/12] create handle_cmdline() function Roy Franz
2014-07-24 7:36 ` Jan Beulich
2014-07-28 15:44 ` Ian Campbell
2014-07-28 15:57 ` Jan Beulich
2014-07-22 0:43 ` [PATCH V2 08/12] Refactor get_argv() for sharing Roy Franz
2014-07-24 7:38 ` Jan Beulich
2014-07-22 0:43 ` [PATCH V2 09/12] Move shared EFI functions to efi-shared.c Roy Franz
2014-07-22 0:43 ` [PATCH V2 10/12] add arm64 cache flushing code from linux Roy Franz
2014-07-28 15:53 ` Ian Campbell
2014-07-28 16:24 ` Ian Campbell
2014-07-22 0:43 ` [PATCH V2 11/12] Add fdt_create_empty_tree() function Roy Franz
2014-07-22 16:36 ` [Linaro-uefi] " Julien Grall
2014-07-22 17:12 ` Roy Franz
2014-07-22 17:15 ` Julien Grall
2014-07-23 9:58 ` Ian Campbell
2014-07-23 16:15 ` Roy Franz
2014-07-22 0:43 ` [PATCH V2 12/12] Add EFI stub for arm64 Roy Franz
2014-07-29 9:46 ` Ian Campbell
2014-07-28 15:30 ` [PATCH V2 00/12] arm64 EFI stub Ian Campbell
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=CAFECyb-0xBht9mdgZe2ohmMF3UheT1hnV3bkaACA+VtON7MVZg@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=linaro-uefi@lists.linaro.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).