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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.