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
_______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
