The embedded space contains a vast number of boards, often only
different by what devices are use, where they are located, etc.
Building a new version of qemu for each board would be burdensome.
The hope would be that we could build a generic qemu (for an
architecture family), say, ppc_generic, which then read an external
file (which, in our case, will be generated from board description)
and configure itself according to that. Further, by allowing devices
to be loaded vi dlopen(), devices can be added after qemu has been
built. This would also allow the developer to specify the exact
location of the device, rather than having a list of IRQ's and base
ports, etc.
For the embedded world, yes, "outsiders" are certainly going to want
to define new platforms and more than likely, provide their own
custom devices. They key is they do not need to muck with the real
internals of qemu, just the part that picks the bits and pieces to use.
Oh, and if I am an outsider, then absolutely the answer is yes!, I
already have had the need :-)
-Paul
On Jul 26, 2007, at 3:48 PM, n schembr wrote:
-snap-
Personally though I don't see much benefit to simple syntax config
files over C files, that are being used now.
Config files implies a self check process. A better question might
be, has qemu grown to the point where an outsider is going to
define a new platform?
Could an arm based cell phone manufacture use the config files to
define the hardware for the emulator without a full port? Iphone
anyone :)
Nicholas A. Schembri
state college pa usa
