[Qemu-devel] Unified device model

["pete sullivan" <sulpete@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2681 bytes --]

Hi

I have been following the discussion about some more dynamic way to
configure and define a simulation set-up
for Qemu. If You want to attract others than hard core developers, I think
that an unified device model is
something to aim for. With a generic device model I think you open up a sea
of possibilities for Qemu.

There are for sure conflicting interests among the users (and potential
users) of Qemu (not to talk about the
developers), ranging from those who are satisfied with a monolith acting as
some well defined machine, to
those that want to runt different configurations on every launch. Take
beyond that,there might as well be a
need for some users to test configurations that is unimaginable be the
developers, as well as running a network
of interconnected machines in a deterministic way. But I hope that there is
a common denominator that
all can agree on, some minimal changes that are required to satisfy a larger
community of both users
and developers. I acknowledge that fact that Fabrice calls the shots, but I
only want to emphasize a few points
that I think are required to be solved for Qemu to really lift off.

What is the smallest set of requirements on a device model that Qemu
developers can embrace? Few
questions comes to my mind
* Is it a framework that requires the models to be open source, or is a
truly dynamic one with DLL files with
  well defined interfaces something to strive for? I strongly believe that a
dynamic model is a prerequisite to
  enable sharing of devices, open source or not.
* Scripting languages, what about those? Can we agree upon some language to
use for configurations
  definitions, like Haskel, M, Tcl, XML or elisp? A scripting language makes
it fairly easy for an inexperienced
  user to create and alters configurations, those configurations can also
describe well defined state for a machine.
  Think, in terms of not booting windowz every time you need it for some
obscure task.
* What about interface definition languages (IDL)? By using an IDL it is
possible to auto generate proxies
  for different requirements, like wrappers for devices developed for Bochs,
Mame and so on, as well as remove
  the not so important important part on how to interconnect components (the
technical aspects).
* All this comes with a performance penalty, is that acceptable? As soon as
you add any kind of dynamic
  device model, you more or less have to remove all global variables and
most of the global functions.


Fellow developers, what do you say? And most importantly, what do You,
Fabrice say, is the above something
that Qemu can evolve into?

BR
Pete

[-- Attachment #2: Type: text/html, Size: 2979 bytes --]