All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.