qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]