[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devi
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices |
Date: |
Mon, 27 Jun 2011 03:26:07 +0100 |
User-agent: |
KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.3; x86_64; ; ) |
> On Mon, Jun 20, 2011 at 6:23 PM, Paul Brook <address@hidden> 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
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, (continued)
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Blue Swirl, 2011/06/13
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Anthony Liguori, 2011/06/14
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Blue Swirl, 2011/06/15
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Anthony Liguori, 2011/06/15
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Blue Swirl, 2011/06/15
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Paul Brook, 2011/06/20
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Blue Swirl, 2011/06/20
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Avi Kivity, 2011/06/21
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices,
Paul Brook <=
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Gleb Natapov, 2011/06/13
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Andreas Färber, 2011/06/10