qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qdev for programmers writeup
Date: Mon, 11 Jul 2011 11:46:32 +0100	[thread overview]
Message-ID: <CAFEAcA8ZOUv_5tBCKd=4E9MGzFB_c-RwceUGgfGT-wT-wn4MSw@mail.gmail.com> (raw)
In-Reply-To: <iveip7$of1$1@dough.gmane.org>

On 11 July 2011 11:20, Paolo Bonzini <pbonzini@redhat.com> wrote:

This is cool; more qdev documentation is really useful.

One point I'd like clarification on is when you need to invent
a new bus type. Sometimes it's pretty obvious because there's
a real hardware bus type there (PCI, SCSI) that you're modelling.
It's the edge cases I find confusing -- for instance, do we need
a qbus for the connection between an SD card controller and the
SD card model (hw/sd.c) ? There's a well defined pluggable interface
between those two parts but there's only ever one SD card so a "bus"
would be a bit odd.

> The first step is very important to achieve a "quality" conversion
> to qdev.  QEMU includes partial conversions to qdev that have a large
> amount of SysBus devices, or devices that use DEFINE_PROP_PTR.  In many
> cases, this is because the authors did not introduce a board-specific
> bus type to mediate access to the board resources.  Together with such
> a bus type there should be a single root board-specific device that is
> attached to SysBus.  An interrupt controller is usually a good candidate
> for this because it takes qemu_irqs from the outside, and can make good
> use of the specificities of SysBus.

...and this bit I don't understand. Why is SysBus a bad thing? It
generally seems to me to be the right way to represent a bit of
hardware which is fundamentally providing a memory mapped interface
plus some GPIO lines. If you make your board use sysbus then it's
easy to just plug in any existing sysbus device model qemu already
has; if every board has its own bus type instead then this reuse
just becomes unnecessarily harder, it seems to me.

Also having the interrupt controller be the board specific device
which you attach to sysbus seems totally wrong to me. This doesn't
match hardware at all -- the interrupt controller deals with
interrupt lines and isn't in the path for memory transactions at
all. (The hierarchy for memory accesses may be completely different
from how interrupts are wired, for that matter.)

-- PMM

  reply	other threads:[~2011-07-11 10:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-11 10:20 [Qemu-devel] qdev for programmers writeup Paolo Bonzini
2011-07-11 10:46 ` Peter Maydell [this message]
2011-07-11 12:48   ` Paolo Bonzini
2011-07-11 14:44     ` Peter Maydell
2011-07-11 15:29       ` Paolo Bonzini
2011-07-11 16:47         ` Peter Maydell
2011-07-12 15:22           ` Paolo Bonzini

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='CAFEAcA8ZOUv_5tBCKd=4E9MGzFB_c-RwceUGgfGT-wT-wn4MSw@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --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).