From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qb1Wh-0001aM-Q0 for qemu-devel@nongnu.org; Sun, 26 Jun 2011 22:26:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qb1Wg-00042U-Jt for qemu-devel@nongnu.org; Sun, 26 Jun 2011 22:26:15 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:50392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qb1Wg-00042D-CO for qemu-devel@nongnu.org; Sun, 26 Jun 2011 22:26:14 -0400 From: Paul Brook Date: Mon, 27 Jun 2011 03:26:07 +0100 References: <1307532813-27175-1-git-send-email-peter.maydell@linaro.org> <201106201623.58992.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201106270326.08131.paul@codesourcery.com> Subject: Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Peter Maydell , Juha =?utf-8?q?Riihim=C3=A4ki?= , "patches@linaro.org" , Jan Kiszka , Markus Armbruster , "qemu-devel@nongnu.org" , Avi Kivity > On Mon, Jun 20, 2011 at 6:23 PM, Paul Brook 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