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 for-4.5 V7 11/14] Add arch specific module handling to read_file()
Date: Thu, 25 Sep 2014 11:52:23 -0700 [thread overview]
Message-ID: <CAFECyb9-F-kKyhFoOYSLMqCDfjKfcrjXiRe_vL-0xBhOqW2yBg@mail.gmail.com> (raw)
In-Reply-To: <CAFECyb93TbojrT7wygcV6TC8RMfrZg9NifJxw8ivA_z1fWvjcw@mail.gmail.com>
On Thu, Sep 25, 2014 at 9:44 AM, Roy Franz <roy.franz@linaro.org> wrote:
> On Thu, Sep 25, 2014 at 3:34 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 25.09.14 at 03:42, <roy.franz@linaro.org> wrote:
>>> + /*
>>> + * 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");
>>
>> Kind of disappointing: You said you'd drop these ERROR prefixes,
>> but this is the second one I come across. I'm ditching them in
>> preparation for committing.
>>
>>> +
>>> + local_name.w = ptr;
>>> + wstrcpy(local_name.w, name);
>>> + w2s(&local_name);
>>> +
>>> + place_string(&mb_modules[mbi.mods_count].string, options);
>>> + place_string(&mb_modules[mbi.mods_count].string, "");
>>
>> Hmm, this one's still here, and I don't recall having seen an
>> explanation for it. I guess I need to cut off committing at this
>> patch then...
>>
The original code put the entire line from the config file into the
mb_modules[i].string field,
which consists of the filename and module options, space separated.
This was done at the
same time the filename was extracted to pass to read_file().
My refactored version of read_file() takes a filename and option
string as separate arguments,
and then after the file is loaded and address known, the module info is updated.
The efi_arch_handle_module() gets the filename and options separately,
and the above place_string()
commands reconstruct the the single string of filename followed by
options that is placed
in the mb_modules[i].string field.
I will add a comment to this effect, and also only add the options if
present, since for
several module types options will be NULL.
>
> I apologize - I missed adding the above to items to my checklist, and
> was likely too focused
> on getting an updated set out yesterday so these items got missed.
>
>>> @@ -861,16 +882,16 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
>>> name.s = get_value(&cfg, section.s, "ramdisk");
>>> if ( name.s )
>>> {
>>> - split_value(name.s);
>>> - read_file(dir_handle, s2w(&name), &ramdisk);
>>> + option_str = split_string(name.s);
>>> + read_file(dir_handle, s2w(&name), &ramdisk, option_str);
>>
>> As said before, this should be NULL as not having and never going to
>> have a consumer. Whether you keep the XSM one below is - as also
>> said before - up to you.
>>
>> Jan
>
> I'll drop the options for ramdisk and xsm. I addresses the options on
> the ucode module,
> which is what you had previously commented on.
>
> I will rebase on staging ( or master if they get pushed there today)
> to get the patches you have already committed.
>
> Roy
>
>>
>>> efi_bs->FreePool(name.w);
>>> }
>>>
>>> name.s = get_value(&cfg, section.s, "xsm");
>>> if ( name.s )
>>> {
>>> - split_value(name.s);
>>> - read_file(dir_handle, s2w(&name), &xsm);
>>> + option_str = split_string(name.s);
>>> + read_file(dir_handle, s2w(&name), &xsm, option_str);
>>> efi_bs->FreePool(name.w);
>>> }
>>>
>>
>>
next prev parent reply other threads:[~2014-09-25 18:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-25 1:42 [PATCH for-4.5 V7 00/14] arm64 EFI stub Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 01/14] x86/EFI: fix freeing of uninitialized pointer Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 02/14] move x86 EFI boot/runtime code to common/efi Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 03/14] Move x86 specific funtions/variables to arch header Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 04/14] create arch functions to allocate memory for and process EFI memory map Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 05/14] Add architecture functions for pre/post ExitBootServices Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 06/14] Add efi_arch_cfg_file_early/late() to handle arch specific cfg file fields Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 07/14] Add efi_arch_handle_cmdline() for processing commandline Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 08/14] Move x86 specific disk probing code Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 09/14] Create arch functions for console and video init Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 10/14] Add efi_arch_memory() for arch specific memory setup Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 11/14] Add arch specific module handling to read_file() Roy Franz
2014-09-25 10:34 ` Jan Beulich
2014-09-25 16:44 ` Roy Franz
2014-09-25 18:52 ` Roy Franz [this message]
2014-09-26 0:25 ` Roy Franz
2014-09-26 6:25 ` Jan Beulich
2014-09-25 1:42 ` [PATCH for-4.5 V7 12/14] Add several misc. arch functions for EFI boot code Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 13/14] Add efi_arch_use_config_file() function to control use of config file Roy Franz
2014-09-25 1:42 ` [PATCH for-4.5 V7 14/14] Add ARM EFI boot support Roy Franz
2014-09-25 10:49 ` Jan Beulich
2014-09-25 17:05 ` Roy Franz
2014-09-26 6:28 ` Jan Beulich
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=CAFECyb9-F-kKyhFoOYSLMqCDfjKfcrjXiRe_vL-0xBhOqW2yBg@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).