From: Paolo Bonzini <pbonzini@redhat.com>
To: Amos Kong <akong@redhat.com>
Cc: aliguori@us.ibm.com, kevin@koconnor.net, seabios@seabios.org,
qemu-devel@nongnu.org, qemu-stable@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] qdev: don't add typename to fw_dev_path when get_fw_dev_path isn't implemented
Date: Wed, 29 May 2013 08:27:48 +0200 [thread overview]
Message-ID: <51A59FE4.30308@redhat.com> (raw)
In-Reply-To: <20130529044137.GB2432@t430s.nay.redhat.com>
Il 29/05/2013 06:41, Amos Kong ha scritto:
> On Tue, May 28, 2013 at 01:15:57PM +0200, Paolo Bonzini wrote:
>> Il 28/05/2013 13:00, Amos Kong ha scritto:
>>> Recent virtio refactoring in QEMU made virtio-bus become the parent bus
>>> of scsi-bus, and virtio-bus doesn't have get_fw_dev_path implementation,
>>> so redundant typename will be added to fw_dev_path. It causes that
>>> bootindex parameter of scsi device doesn't work.
>>>
>>> This patch changes qdev_get_fw_dev_path_helper() to add nothing if
>>> implemented get_fw_dev_path() returns NULL.
>>>
>>> Signed-off-by: Amos Kong <akong@redhat.com>
>>> --
>>> v2: only add nothing to fw_dev_path when get_fw_dev_path() is
>>> implemented and return NULL. then it will not effect other devices
>>> don't have get_fw_dev_path() implementation.
>
> Hi Paolo,
>
>> To achieve the same result, you can simply ensure that all classes
>> implement the method.
>
> Do you mean if some classes didn't have an implement, I need to add
> a implement (just returns NULL) for all of them, then nothing will be
> added to fw_dev_path for those classes?
No, you can have an implementation in BusClass. See how
device_class_init provides a default implementation for
realize/unrealize, and do the same in bus_class_init.
> Currently I'm sure 'typename' is redundant for virio-bus. 'typename'
> might be needed for other class (have no get_fw_dev_path implementation)
>
> Applied patch v2, there are three conditions:
> 1) implement get_fw_dev_path, return specific string, add to
> fw_dev_path (same as original)
> 2) don't implement get_fw_dev_path, add typename to fw_dev_path.
> (same as original)
> 3) implement get_fw_dev_path and return NULL, nothing is added
> to fw_dev_path (new behavior)
>
> If some other class wants to add nothing to path, just define a method
> to return NULL.
>
>> The default implementation is just
>> g_strdup(object_get_typename(OBJECT(dev))).
>
> If we implement the method for all classes, the default implementation
> in qdev_get_fw_dev_path_helper() will not be called.
Yes, but we shouldn't implement the method for all classes. We should
implement it just once in BusClass. Then the default implementation in
qdev_get_fw_dev_path_helper() can be removed. It will live in BusClass
instead
Paolo
>> Remember that if you do not specify a method in a BusClass's class_init
>> function, it is inherited from the superclass.
>>
>> Paolo
>
next prev parent reply other threads:[~2013-05-29 6:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-28 11:00 [Qemu-devel] [PATCH v2] qdev: don't add typename to fw_dev_path when get_fw_dev_path isn't implemented Amos Kong
2013-05-28 11:15 ` Paolo Bonzini
2013-05-29 4:41 ` Amos Kong
2013-05-29 6:27 ` Paolo Bonzini [this message]
2013-05-28 11:18 ` Amos Kong
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=51A59FE4.30308@redhat.com \
--to=pbonzini@redhat.com \
--cc=akong@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=kevin@koconnor.net \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=seabios@seabios.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).