From: Gonglei <arei.gonglei@huawei.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Huangpeng (Peter)" <peter.huangpeng@huawei.com>,
"Huangweidong (C)" <weidong.huang@huawei.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Subo (A)" <subo7@huawei.com>, "mst@redhat.com" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/4] qdev: support to get a device firmware path directly
Date: Thu, 22 Jan 2015 09:04:51 +0800 [thread overview]
Message-ID: <54C04CB3.3060908@huawei.com> (raw)
In-Reply-To: <54BF84F0.9090201@redhat.com>
On 2015/1/21 18:52, Paolo Bonzini wrote:
>
>
> On 21/01/2015 03:14, Gonglei wrote:
>> On 2015/1/21 0:10, Paolo Bonzini wrote:
>>
>>>
>>>
>>> On 19/01/2015 14:23, arei.gonglei@huawei.com wrote:
>>>> @@ -780,6 +788,12 @@ static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
>>>> d = bus_get_fw_dev_path(dev->parent_bus, dev);
>>>> }
>>>> if (d) {
>>>> + l += snprintf(p + l, size - l, "%s/", d);
>>>> + g_free(d);
>>>> + }
>>>> +
>>>> + d = qdev_get_own_fw_dev_path_from_handler(dev->parent_bus, dev);
>>>
>>> This changes preexisting behavior. If d was true, you wouldn't go down
>>> the following else. Now it does.
>>>
>>
>> On the face of things, it is. But actually they are equal. Please notice I added a "/" at the
>> end p, and then the function can return if d was NULL.
>> l += snprintf(p + l, size - l, "%s/", d);
>
> But in this case I think the "return l" should become unconditional.
> It should move out of the "else".
>
After calling qdev_get_own_fw_dev_path_from_handler(), if d was true, there is also
l += snprintf(p + l, size - l, "%s", d);
we still have to add a '/' too. These two situation are different.
>>> I was thinking it should be handled though the "suffix" argument to
>>> add_boot_device_path, but that's harder now that the suffix has to be
>>> passed to device_add_bootindex_property.
>>>
>>
>> Yes.
>>
>>> Perhaps you could call qdev_get_own_fw_dev_path_from_handler in
>>> get_boot_devices_list, and convert non-NULL suffixes to implementations
>>> of FWPathProvider?
>>
>> Maybe your meaning is "convert NULL suffixes to implementations
>> of FWPathProvider"? Something like below:
>
> No, I meant non-NULL.
>
> In the beginning it can be something like this:
>
> diff --git a/bootdevice.c b/bootdevice.c
> index 5914417..916bfb7 100644
> --- a/bootdevice.c
> +++ b/bootdevice.c
> @@ -210,7 +210,8 @@ char *get_boot_devices_list(size_t *size, bool ignore_suffixes)
> char *list = NULL;
>
> QTAILQ_FOREACH(i, &fw_boot_order, link) {
> - char *devpath = NULL, *bootpath;
> + char *devpath = NULL, *suffix = NULL;
> + char *bootpath;
> size_t len;
>
> if (i->dev) {
> @@ -218,21 +219,22 @@ char *get_boot_devices_list(size_t *size, bool ignore_suffixes)
> assert(devpath);
> }
>
> - if (i->suffix && !ignore_suffixes && devpath) {
> - size_t bootpathlen = strlen(devpath) + strlen(i->suffix) + 1;
> -
> - bootpath = g_malloc(bootpathlen);
> - snprintf(bootpath, bootpathlen, "%s%s", devpath, i->suffix);
> - g_free(devpath);
> - } else if (devpath) {
> - bootpath = devpath;
> - } else if (!ignore_suffixes) {
> - assert(i->suffix);
> - bootpath = g_strdup(i->suffix);
> - } else {
> - bootpath = g_strdup("");
> + if (!ignore_suffixes) {
> + d = qdev_get_own_fw_dev_path_from_handler(i->dev->parent_bus, i->dev);
> + if (d) {
> + assert(!i->suffix);
> + suffix = d;
> + } else {
> + suffix = g_strdup(i->suffix);
> + }
> }
>
> + bootpath = g_strdup_printf("%s%s",
> + devpath ? devpath : "",
> + suffix ? suffix : "");
> + g_free(devpath);
> + g_free(suffix);
> +
> if (total) {
> list[total-1] = '\n';
> }
>
>
> Then as time permits the suffix can be phased out and replaced by
> FWPathProvider on the device.
>
Anyway, I like your approach, it's so clear. :)
Regards,
-Gonglei
next prev parent reply other threads:[~2015-01-22 1:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-19 13:23 [Qemu-devel] [PATCH 0/4] vhost-scsi: support to assign boot order arei.gonglei
2015-01-19 13:23 ` [Qemu-devel] [PATCH 1/4] qdev: support to get a device firmware path directly arei.gonglei
2015-01-20 16:10 ` Paolo Bonzini
2015-01-21 2:14 ` Gonglei
2015-01-21 10:52 ` Paolo Bonzini
2015-01-22 1:04 ` Gonglei [this message]
2015-01-19 13:23 ` [Qemu-devel] [PATCH 2/4] vhost-scsi: add bootindex property arei.gonglei
2015-01-19 13:23 ` [Qemu-devel] [PATCH 3/4] vhost-scsi: realize the TYPE_FW_PATH_PROVIDER interface arei.gonglei
2015-01-19 13:23 ` [Qemu-devel] [PATCH 4/4] vhost-scsi: add an ioctl interface to get target id arei.gonglei
2015-01-19 21:51 ` Michael S. Tsirkin
2015-01-26 8:00 ` Gonglei
2015-01-26 9:32 ` Paolo Bonzini
2015-01-26 12:13 ` Gonglei
2015-01-26 12:16 ` Paolo Bonzini
2015-01-26 12:23 ` Gonglei
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=54C04CB3.3060908@huawei.com \
--to=arei.gonglei@huawei.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.huangpeng@huawei.com \
--cc=qemu-devel@nongnu.org \
--cc=subo7@huawei.com \
--cc=weidong.huang@huawei.com \
/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).