Re: [Qemu-devel] Unified device model

[Jim C. Brown]

On Sun, Apr 09, 2006 at 08:26:11AM +0200, Stanislav Shwartsman wrote:
> I am talking about the device models only. Inside CPU emulation QEMU, Bochs
> and Xen are completely different, but they use the same devices for full
> system emulation and they most likely want to move forward together.

I haven't kept up with Bochs lately, so I have no idea if what qemu emulates
and what Bochs emulates are still the same or if the devices supported have
divulged.

I do know that the code is completely different (they aren't even in the same
language!).

This part of the discussion is getting offtopic tho - how devices are done
right now is not important.

> The
> devices system of QEMU and Bochs become outdate, it is required to add ACPI
> compliance and emulate new modern ACPI compatible devices, currently
> emulated i440FX already not so represent the real life and most of the
> modern OSes already have no support for it.
> 

Agreed.

> So may we should ;)

Agreed.

> At least I see the code changes from Bochs migrating to QEMU and vise versa
> when I am looking into the code.
> 

You do?

I wasn't aware that bochs took anything from qemu, and the only piece of code
that I know that is shared between the two is for the bios.

> Why not ?
> You always could consider to add simple modules C++ to QEMU or build C++
> device -> C device interface bridge ...
> I don't know all the possibilities, but I am sure there are more.

C++ code in qemu is forbidden (by the author and maintainer).

So a plugin API based on C sounds like the best option.

Bochs is unique as it is the only active open source PC emulator/virtualizer 
that
is done in C++. So "Bochs has C++ support" is not a good reason for the API
to be based on C++.

> 
> >>I know about two professional teams working in simulation which would like
> >>to use these device models in their simulator and 
> >>could enrich the device library with new devices device interfaces, for
> >>example with AGP and 3D graphics.
> >>Bochs is already in middle of definition of new true pluginable devices
> >>architecture. 
> 
> >This is welcome news.
> 
> Currently we are thinking about making user-plugin PCI devices and when
> later user-plugin for any device. The C++ hierarchy for now might be:
> bx_devmodel_c - bx_pcidev_c - bx_user_pcidev_c
> 
> The plans are to take one of the Bochs PCI devices and convert it into
> user-level plugin which should not be compiled with Bochs and even not known
> at compile time, but loaded at runtime if selected in runtime config file.

Why only PCI devices?

Why not USB, ISA (keyboard, monitor, pc speaker), devices that attach to the
serial port (like the current wacom patch), etc?

Also note that it is possible to use C to set up such a hierarchy - perhaps
not as natural as in C++, but still doable.

> When any other device models could be added, even with closed-sources and
> commercial licenses.

I don't support this.

Under what circumstances would commercial qemu/xen/bochs/eos driver devices
be a good thing?

I can understand (tho I still dislike) having commercial drivers in say
the kernel - if its the only way to get support for a particular device, and
that device would make it easier for others to use a different OS (e.g.
nvidia under linux so ppl can have good 3d support) then I find it acceptable
and tolerable.

But why would we want to do this for qemu et. al.?

> 
> >The primary reason given for not making a plugin API for qemu hardware
> >emulationis that qemu isn't stable enough - the code changes too often to
> >support a stable API.
> 
> >Still, it might be easier to add support for plugins based on an external
> >API, rather than trying to keep a qemu plugin API consistent.
> 
> Ok, I didn't knew that QEMU is so unstable. But at least there are several
> trivial requirements from plugin architecture which you could mention here
> and I am still not thought about it. I know, basically I am writing the
> definition in my idle time and Volker supporting me. But it is not enough
> ...

If I think of anything else, I'll let you know. I do want to see this happen.

> 
> Thanks,
> Stanislav
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.