> On Mon, Jun 20, 2011 at 6:23 PM, Paul Brook <p...@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
