From: "Andreas Färber" <afaerber@suse.de>
To: Scott Wood <scottwood@freescale.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
Bhushan Bharat-R65777 <R65777@freescale.com>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
Alexander Graf <agraf@suse.de>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH: RFC] Adding BAR0 for e500 PCI controller
Date: Tue, 11 Sep 2012 14:23:29 +0200 [thread overview]
Message-ID: <504F2D41.6000404@suse.de> (raw)
In-Reply-To: <504A43EC.6030004@freescale.com>
Am 07.09.2012 20:58, schrieb Scott Wood:
> On 09/07/2012 03:08 AM, Alexander Graf wrote:
>>
>> On 07.09.2012, at 01:15, Scott Wood <scottwood@freescale.com> wrote:
>>
>>> On 09/03/2012 01:44 AM, Bhushan Bharat-R65777 wrote:
>>>>
>>>> Can we somehow pass this via qdev/varargs from machine emulation code
>>>> (hw/ppc/e500.c) ?
>>>
>>> Possibly, though it may not be the best idea to express every single
>>> aspect of intercomponent integration via qdev -- maybe that's best left
>>> for things that are reasonably user-tweakable. If CCSR size is user
>>> tweakable, it would be somewhere other than the PCI controller.
>>
>> It depends. Qdev properties are basically object constructor
>> parameters. So if you were weiting C++ code and would have a
>> constructor that gets the size as argument, it would end up being
>> modeled as qdev property.
>>
>> If however actual functionality differs, thus you would in OO speech
>> create a subclass / child class, then you are better off creating a
>> new device struct.
>>
>> In this case, I'm not sure. They are different devices really, but
>> are close enough that the differences could be expressed through qdev
>> properties.
>
> I wasn't suggesting that they be different devices. I was suggesting
> that this isn't a property of the PCI controller, but rather of some
> other entity to which the PCI controller connects. So maybe a reference
> to the associated CCSR object would be a qdev parameter, but not the
> size of that CCSR.
For a reference to another object a QOM link<> property would be
preferred over a static qdev property.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2012-09-11 12:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 12:50 [Qemu-devel] [PATCH: RFC] Adding BAR0 for e500 PCI controller Bharat Bhushan
2012-08-15 1:29 ` [Qemu-devel] [Qemu-ppc] " Scott Wood
2012-08-15 2:40 ` Bhushan Bharat-R65777
2012-09-03 6:44 ` Bhushan Bharat-R65777
2012-09-06 23:15 ` Scott Wood
2012-09-07 8:08 ` Alexander Graf
2012-09-07 18:58 ` Scott Wood
2012-09-11 11:33 ` Alexander Graf
2012-09-11 19:05 ` Scott Wood
2012-09-11 20:58 ` Alexander Graf
2012-09-11 12:23 ` Andreas Färber [this message]
2012-09-11 12:27 ` Alexander Graf
2012-09-11 12:59 ` Andreas Färber
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=504F2D41.6000404@suse.de \
--to=afaerber@suse.de \
--cc=B07421@freescale.com \
--cc=R65777@freescale.com \
--cc=agraf@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=scottwood@freescale.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).