> But there are two distinct classes of user. One class of user really is > thinking: > > "I want a KVM virtual machine, with 3 disks and 2 network cards" > > They could give a flying hoot whether the i440fx inherits from pcidevice or > implements pcibus. > > We need to provide an obviously distinct UI and API for these users. The > vast majority of command line users fall into this category. And once > this user learns how do create a guest with 3 disks and 2 network cards, > they should never have to learn another way of doing it.
Ok. > There is a second class of "user" that is doing very sophisticated things > and cares about this information. But this sophisticated user (i.e. > libvirt) wants to be able to probe QEMU to understand what features > are probably available because it very likely is evolving just as quickly as > QEMU is. I disagree. Maybe this is because you're coming from the PC/Linux world where all hardware is basically the same. In the embedded world there are many more vastly different machines. And some of those have several similar but different enough to matter variants. There's a good chance the guest OS needs exactly the right one. Take the Stellaris boards as an example. We currently implement two boards. There are well over a hundred variants in this SoC family. A good proportion of these chips will be used in projects that include a custom PCB design. There are at least three different reference boards for the LM3S6965 alone. This is not unusual. I really don't want to have to teach qemu about hunderds of different SoCs connected to thousands of different "motherboards", most of which we'll never even know about. I'd like for users to be able to create their own hardware config without having to track qemu implementation details. I'm fine with having to hack/rebuild qemu to add a new device implementation. Having to do that for every trivial rewiring of existing devices is not so fun. > > I haven't worked out the details, maybe we need a "Self" property, plus a > > policy of never having user visible stuff link to an primary device node. > > If the primary object happens to implement/inherit from that Interface > > then it sets the property to itself. Otherwise it creates a stateful > > bus object (maybe using composition). > > You're advocating only connecting properties to properties, and never an > object to a property? I think that's needlessly complicated. In the vast > majority of cases, you just case about saying "connect this > CharDriverState to this Serial device". We should make it much more > complicated than that. Yes, that's what I'm saying. I'm finding it hard to believe that more than one link being stateful is such an exceptional case. Am I right in thinking that you're effectively implementing multiple inheritance via properties? If so I guess works around the single-inheritance limitation in many cases. > >>>> If you aren't using inheritance, yes, you need to pass closures to the > >>>> child objects. I dislike that kind of proxy modeling. > >>> > >>> How would you solve this using inheritance? > >>> > >>> I can see how it works when the device knows its address, but it seems > >>> kinda lame to tell a device "You have a dedicated communication > >>> channel. > >>> > >>> But I'm lazy and will smush them all together. Please add this > >>> > >>> additional token to every signal you send". > >> > >> Yes, adding a token is how you would have to do it. > > > > Ugh. Except it's worse than I thought. That token has to come from the > > user. Either via some arbitrary property on the client device, which is > > going to be different for every device especially when a device can link > > to multiple interfaces of the same class. Or we need some mechanism for > > attaching data to a link, rather than just conecting the two interfaces > > together. Neither of which sound desirable. > > But this entire use-case seems to be synthetic. Do you have a real case > where you would want to inherit twice from the same interface? A GPIO controller (of which interrupt controllers are a subset). We want to expose and use many single-bit control line interfaces. I suppose pckbd.c is annother example. This implements a pair of PS/2 serial busses. Currently we don't model these and use hardcoded callbacks when creating the keyboard/mouse devices. Once modelled properly I'd expect a board to be able to replace either with a third [as yet unimplemented] PS/2 device. Any of the those devices should also be usable with the single-port ARM PL050 controller. Paul
