From: Paul Brook <paul@codesourcery.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Juha Riihimäki" <juha.riihimaki@nokia.com>,
"patches@linaro.org" <patches@linaro.org>,
"Jan Kiszka" <jan.kiszka@siemens.com>,
"Markus Armbruster" <armbru@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Avi Kivity" <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices
Date: Mon, 27 Jun 2011 03:26:07 +0100 [thread overview]
Message-ID: <201106270326.08131.paul@codesourcery.com> (raw)
In-Reply-To: <BANLkTikC7aopdAsicXnNM=4-F0_w_PcsWQ@mail.gmail.com>
> On Mon, Jun 20, 2011 at 6:23 PM, Paul Brook <paul@codesourcery.com> wrote:
> >> > Yeah, that's why I said, "hard to do well". It makes it very hard to
> >> > add new socket types.
> >>
> >> PCI, USB, IDE, SCSI, SBus, what else? APICBus? I2C? 8 socket types
> >> ought to be enough for anybody.
> >
> > Off the top of my head: AClink (audio), i2s (audio), SSI/SSP (synchonous
> > serial), Firewire, rs232, CAN, FibreChannel, ISA, PS2, ADB (apple desktop
> > bus) and probably a bunch of others I've missed. There's also a bunch
> > of all-but extinct system architectures with interesting bus-level
> > features (MCA, NuBus, etc.)
>
> Are these really buses with identifiable sockets? For example, it's
> not possible to enumerate the users of ISA bus or RS-232.
Why does that matter? The whole point of a "socket" is that it defines the
interaction between two devices. It allows the topology of a system to be
expressed in a device agnostic manner. Currently we only support a simple
bus/device tree hierachy. The fact that we also need to support additional
single-bit unidirectional links (aka GPIO/IRQ) with a completely different
topology is why this conversation started.
If done properly, sockets should entirely replace the existing bust/device
split. This just becomes a set of links between sockets of the appropriate
type.
An actual bus topology implies a socket has more than a single point-point
connection. Whether we actually impletment this is something of an open
question. Physical hardware always has a finite number of connection points so
worst case you end up explicitly modelling that as a separate multiport "bus"
device, or by daisy-chaining passthrough sockets. If we do want to model a
pure bus (without physically identifiable ports) then I'd probably go for a
simple one-many connector, allowing the majority of the code to still treat it
as a single link connection. Device addressing can be handled by higher level
bus/socket specific APIs.
Paul
next prev parent reply other threads:[~2011-06-27 2:26 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-08 11:33 [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices Peter Maydell
2011-06-08 11:33 ` [Qemu-devel] [PATCH RFC 1/3] sysbus: Add support for resizing and unmapping MMIOs Peter Maydell
2011-06-08 11:33 ` [Qemu-devel] [PATCH RFC 2/3] sysbus: Allow sysbus MMIO passthrough Peter Maydell
2011-06-08 11:33 ` [Qemu-devel] [PATCH RFC 3/3] sysbus: Allow passthrough of single IRQ Peter Maydell
2011-06-08 12:29 ` [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices Jan Kiszka
2011-06-09 16:40 ` Markus Armbruster
2011-06-09 17:03 ` Jan Kiszka
2011-06-10 8:13 ` Markus Armbruster
2011-06-10 12:51 ` Anthony Liguori
2011-06-10 13:10 ` Peter Maydell
2011-06-10 13:43 ` Jan Kiszka
2011-06-10 13:50 ` Peter Maydell
2011-06-10 14:22 ` Markus Armbruster
2011-06-10 14:45 ` Anthony Liguori
2011-06-10 14:34 ` Anthony Liguori
2011-06-10 14:12 ` Anthony Liguori
2011-06-10 14:18 ` Jan Kiszka
2011-06-10 14:31 ` Anthony Liguori
2011-06-10 14:07 ` Anthony Liguori
2011-06-10 14:59 ` Markus Armbruster
2011-06-10 15:43 ` Anthony Liguori
2011-06-12 17:12 ` Avi Kivity
2011-06-12 19:21 ` Anthony Liguori
2011-06-13 8:05 ` Avi Kivity
2011-06-13 17:53 ` Anthony Liguori
2011-06-13 20:59 ` Blue Swirl
2011-06-14 13:21 ` Anthony Liguori
2011-06-15 18:56 ` Blue Swirl
2011-06-15 20:00 ` Anthony Liguori
2011-06-15 20:20 ` Blue Swirl
2011-06-20 15:23 ` Paul Brook
2011-06-20 21:32 ` Blue Swirl
2011-06-21 8:16 ` Avi Kivity
2011-06-27 2:26 ` Paul Brook [this message]
2011-06-13 9:57 ` Gleb Natapov
2011-06-10 16:28 ` 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=201106270326.08131.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=armbru@redhat.com \
--cc=avi@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=jan.kiszka@siemens.com \
--cc=juha.riihimaki@nokia.com \
--cc=patches@linaro.org \
--cc=peter.maydell@linaro.org \
--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 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.