On Tue, 2007-09-04 at 23:27 +0100, Thiemo Seufer wrote:
> Brian Johnson wrote:
> [snip]
> >> My initial thought is to make the libraries at the individual device
> >> level.
> >
> > It would be good to have a general mechanism for bus providers, interrupts, 
> > APICs, chipsets, etc. as well, so we could emulate fancier architectures 
> > than a simple PC (or simple Sparc/MIPS/ARM/etc. box.)  For instance, I'd 
> > like to emulate multiple PCIe host bridges, each with an APIC and multiple 
> > cards, which might contain PCI-to-PCI bridges.  And I'd like to emulate 
> > NUMA systems with many memory controllers and a complex memory map, with 
> > multiple sets of chipset registers.  I don't expect qemu to do this off the 
> > shelf,
> 
> Why not? I would like to see better abstracted and more capable device
> emulations in Qemu.
> 
> > but I'd like to avoid hardcoding PC assumptions into the device 
> > libraries, so I can code the fancy machines myself and use the I/O as-is.
> 
> Then, what does a librar-ized Qemu device with its hardcoded PC
> assumptions help you?
> 
> One reason why I don't like the idea is that it introduces a external
> interface which is hard to maintain.

It just depends on how you support the interface.  There's really
nothing wrong with having a per-device version #define and making no
guarantees that the interface stays consistent across versions.  The
goal isn't to have a third party tool be able to use *any* version of
QEMU's device model but rather to allow it to use *some* version of it
instead of forking it into it's own code base.

However, I don't think that the interface would change that much anyway.

Regards,

Anthony Liguori

> 
> Thiemo
> 
> 



Reply via email to