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 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);
>>>      }
>>>
>>
>>

  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).