[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: QEmu as a Device Software Optimization tool

From: Paul Sokolovsky
Subject: Re: [Qemu-devel] Re: QEmu as a Device Software Optimization tool
Date: Sat, 28 Jul 2007 19:54:05 +0300


Andrzej Zaborowski wrote:

> There is some interesting work being done on a similar project by Paul
> Sokolovsky for his and Maria Zabolotnaya's Google Summer Of Project.

  Yes, there's such project, being done from Handhelds.org, with the
motivation that the project works on porting Linux to several dozens of
PDA, while having less than a dozen people active in any given time,
and concentrating on small subset of devices. Thus, to leverage
emulation technology to our devices (and this brings obvious
benefits), there would need to be rapid prototyping technology
allowing easy reuse of already existing components.

  The project itself is more proof-of-concept though.

Friday, July 27, 2007, 12:46:29 PM, Paul Borman wrote:

> The platform I started with was ppc_prep :-)

> So, is Python already part of qemu?

  No, but fortunately it's not required at all. The idea is to have
Python wrapper for entire QEMU functionality, so that QEMU can be
completely controlled from Python code. Its relation to QEMU is the
same as that of PyGTK+ and GTK+ - the former should not be part of the

  Such a design besides being a technical best practice, also rooted in
the outcome of the mentioned Oct 2006 discussion, when it became clear
that flexible configuration won't be a part of QEMY any time soon ;-).


> Using python, or some general purpose scripting language, to  
> create .c files for inclusion in the compilation seems like it may  
> have some merit, though I see these as different issues.

  That's not purpose of the Python module in question. Being a wrapper
around QEMU, it would allow to use Python's dynamical and high-level nature
to easily "construct" virtual board as well as handle "boring" tasks
like configuration file parsing, logging etc. So, the module itself
allows to specify machine in "imperative" description. I'm great
proponent of declarative descriptions myself, but designing such would
need more work. Plus, as the old discussion showed, there's no
unanimity even regarding what syntax it should use! (I for one find it
amusing that in 2006 people could think that writing XML parser would
be a prerequisite for XML use, and in even in 2007 come with idea of
"simple ascii files" ;-)).

>   I wrote a  
> PPC virtual machine to run on PPC hosts (i.e., more like vmware).   
> When I found that I wanted a little more than a simple ascii file, I  
> settled on pretty much the standard sh syntax.  I have written (and  
> am willing to contribute) an embedded version of sh which only calls  
> builtin functions.  I used it both for my monitor as well as my  
> config syntax (config files were essentially read by the monitor)

  Good luck pushing it upstream! As I wrote yet back in that thread,
there're more political than technical reasons why QEMU still doesn't
have it, and won't have it for some time more. But of course, raising
awareness and lobbying actions should help with this.

>                 -Paul

>>> Personally though I don't see much benefit to simple syntax config
>>> files over C files, that are being used now.
>> Really? Take a look at ppc_prep_init()...
>> I would love to see machine definition done in python.
>> -- 
>> Hollis Blanchard
>> IBM Linux Technology Center

Best regards,
 Paul                            mailto:address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]