From: Alexander Graf <agraf@suse.de>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-ppc Mailing List <qemu-ppc@nongnu.org>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Eric Auger <eric.auger@linaro.org>
Subject: Re: [Qemu-devel] [PATCH 0/5] Platform device support
Date: Thu, 26 Jun 2014 14:01:24 +0200 [thread overview]
Message-ID: <53AC0B94.3060400@suse.de> (raw)
In-Reply-To: <CAEgOgz4HjJqje4aGYORVY23R4fp=ng_i+BLLgEt1ra++LU5mBA@mail.gmail.com>
On 20.06.14 08:43, Peter Crosthwaite wrote:
> On Wed, Jun 4, 2014 at 10:28 PM, Alexander Graf <agraf@suse.de> wrote:
>> Platforms without ISA and/or PCI have had a seriously hard time in the dynamic
>> device creation world of QEMU. Devices on these were modeled as SysBus devices
>> which can only be instantiated in machine files, not through -device.
>>
>> Why is that so?
>>
>> Well, SysBus is trying to be incredibly generic. It allows you to plug any
>> interrupt sender into any other interrupt receiver. It allows you to map
>> a device's memory regions into any other random memory region. All of that
>> only works from C code or via really complicated command line arguments under
>> discussion upstream right now.
>>
> What you are doing seem to me to be an extension of SysBus - you are
> defining the same interfaces as sysbus but also adding some machine
> specifics wiring info. I think it's a candidate for QOM inheritance to
> avoid having to dup all the sysbus device models for both regular
> sysbus and platform bus. I think your functionality should be added as
> one of
>
> 1: and interface that can be added to sysbus devices
> 2: a new abstraction that inherits from SYS_BUS_DEVICE
> 3: just new features to the sysbus core.
>
> Then both of us are using the same suite of device models and the
> differences between our approaches are limited to machine level
> instantiation method. My gut says #2 is the cleanest.
The more I think about it the more I believe #3 would be the cleanest.
The only thing my platform devices do in addition to sysbus devices is
that it exposes qdev properties to give mapping code hints where a
device wants to be mapped.
If we just add qdev properties for all the possible hints in generic
sysbus core code, we should be able to automatically convert all devices
into dynamically allocatable devices. Whether they actually do get
mapped and the generation of device tree chunks still stays in the the
machine file's court.
Alex
next prev parent reply other threads:[~2014-06-26 12:01 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-04 12:28 [Qemu-devel] [PATCH 0/5] Platform device support Alexander Graf
2014-06-04 12:28 ` [Qemu-devel] [PATCH 1/5] Platform: Add platform device class Alexander Graf
2014-06-19 14:51 ` Eric Auger
2014-06-04 12:28 ` [Qemu-devel] [PATCH 2/5] Platform: Add serial device Alexander Graf
2014-06-04 12:28 ` [Qemu-devel] [PATCH 3/5] PPC: e500: Only create dt entries for existing serial ports Alexander Graf
2014-06-04 12:28 ` [Qemu-devel] [PATCH 4/5] PPC: e500: Support platform devices Alexander Graf
2014-06-13 8:58 ` Bharat.Bhushan
2014-06-13 9:46 ` Alexander Graf
2014-06-19 14:56 ` Eric Auger
2014-06-19 21:40 ` Alexander Graf
2014-06-27 9:29 ` Eric Auger
2014-06-27 11:30 ` Alexander Graf
2014-06-27 16:50 ` Eric Auger
2014-06-04 12:28 ` [Qemu-devel] [PATCH 5/5] PPC: e500: Add support for platform serial devices Alexander Graf
2014-06-19 20:54 ` [Qemu-devel] [PATCH 0/5] Platform device support Paolo Bonzini
2014-06-19 21:38 ` Alexander Graf
2014-06-20 6:43 ` Peter Crosthwaite
2014-06-20 7:39 ` Paolo Bonzini
2014-06-26 12:01 ` Alexander Graf [this message]
2014-06-27 10:30 ` Andreas Färber
2014-06-27 10:54 ` Peter Crosthwaite
2014-06-27 11:17 ` Andreas Färber
2014-06-27 11:24 ` Alexander Graf
2014-06-27 11:48 ` Paolo Bonzini
2014-06-27 11:52 ` Peter Maydell
2014-06-27 12:00 ` Paolo Bonzini
2014-06-27 11:41 ` Alexander Graf
2014-06-27 11:40 ` Alexander Graf
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=53AC0B94.3060400@suse.de \
--to=agraf@suse.de \
--cc=eric.auger@linaro.org \
--cc=pbonzini@redhat.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@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).