From: "Andreas Färber" <afaerber@suse.de>
To: Markus Armbruster <armbru@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Cao jin <caoj.fnst@cn.fujitsu.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] SCSI bus: fix to incomplete QOMify
Date: Mon, 11 Jan 2016 18:57:33 +0100 [thread overview]
Message-ID: <5693ED0D.2080504@suse.de> (raw)
In-Reply-To: <87lh7wt3u7.fsf@blackfin.pond.sub.org>
Am 11.01.2016 um 18:37 schrieb Markus Armbruster:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>> On 07/01/2016 10:53, Cao jin wrote:
>>> On 01/07/2016 05:38 PM, Paolo Bonzini wrote:
>>>> On 06/01/2016 14:43, Cao jin wrote:
>>>> These functions are called in the data path; changes to use SCSI_BUS()
>>>> should come with performance data proving that it doesn't slow down I/O.
>>>
>>> I see. I am not familiar with the procedure of scsi i/o performance
>>> test, do have some guideline about it?
>>
>> Usually people test with FIO, but I think it's simpler to just keep
>> DO_UPCAST here.
>
> DO_UPCAST() needs to die.
>
> SCSI_BUS() is a readable wrapper around OBJECT_CHECK():
>
> #define SCSI_BUS(obj) OBJECT_CHECK(SCSIBus, (obj), TYPE_SCSI_BUS)
>
> OBJECT_CHECK() is semantically a type cast, but in actual code it does
> more:
>
> #define OBJECT_CHECK(type, obj, name) \
> ((type *)object_dynamic_cast_assert(OBJECT(obj), (name), \
> __FILE__, __LINE__, __func__))
>
> Object *object_dynamic_cast_assert(Object *obj, const char *typename,
> const char *file, int line, const char *func)
> {
> trace_object_dynamic_cast_assert(obj ? obj->class->type->name : "(null)",
> typename, file, line, func);
>
> #ifdef CONFIG_QOM_CAST_DEBUG
> [...]
> #endif
> return obj;
> }
>
> If CONFIG_QOM_CAST_DEBUG is on, it checks. That's a feature.
>
> If CONFIG_QOM_CAST_DEBUG is off, it still calls to trace. That might
> be a misfeature.
Ugh, I was not aware of that tracing!
Also, might it make sense to make that ..._assert() function inline?
> If OBJECT_CHECK() isn't fit for fast paths because of that, perhaps QOM
> should provide a conversion macro that is. Andreas, what do you think?
We had a similar issue with virtio fast paths. I'm not sure whether we
kept DO_UPCAST() or used a direct (Foo *) cast though. I think mst was a
fan of upcast, and I used the latter in TCG innards.
The general idea (from Anthony) was that derived types should not know
about the implementation detail that the struct has a field of a certain
name (for example, a switch to C++ classes or something would make it go
away). So there's two issues mixed here, a) going from foo(x,y,z) to
just bar(x) and b) the type checking as part of bar(x).
If you want to propose a FOO_FAST() or whatever, I'm all ears.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
prev parent reply other threads:[~2016-01-11 17:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 13:43 [Qemu-devel] [PATCH] SCSI bus: fix to incomplete QOMify Cao jin
2016-01-07 9:38 ` Paolo Bonzini
2016-01-07 9:53 ` Cao jin
2016-01-07 12:05 ` Paolo Bonzini
2016-01-11 17:37 ` Markus Armbruster
2016-01-11 17:45 ` Peter Maydell
2016-01-11 17:57 ` Andreas Färber [this message]
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=5693ED0D.2080504@suse.de \
--to=afaerber@suse.de \
--cc=armbru@redhat.com \
--cc=caoj.fnst@cn.fujitsu.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.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).