qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Sokolovsky <pmiscml@gmail.com>
To: Paul Borman <paul.borman@windriver.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: QEmu as a Device Software Optimization tool
Date: Sat, 28 Jul 2007 19:54:05 +0300	[thread overview]
Message-ID: <487977679.20070728195405@gmail.com> (raw)
In-Reply-To: <77D52109-7706-4932-AA0F-7437D0B22DAB@windriver.com>

Hello,

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
latter.

  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:pmiscml@gmail.com

  parent reply	other threads:[~2007-07-28 16:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-20 14:58 [Qemu-devel] Patch for OHW bootinfos Tero Kaarlela
2007-07-26 16:34 ` [Qemu-devel] QEmu as a Device Software Optimization tool Paul Borman
2007-07-26 16:58   ` Thiemo Seufer
2007-07-26 17:33   ` Even Rouault
2007-07-26 19:00   ` andrzej zaborowski
2007-07-26 22:16     ` [Qemu-devel] " Hollis Blanchard
2007-07-27  9:46       ` Paul Borman
2007-07-27 11:12         ` Alexander Voropay
2007-07-27 22:54         ` andrzej zaborowski
2007-07-28 16:54         ` Paul Sokolovsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-07-26 19:48 [Qemu-devel] " n schembr
2007-07-27 14:24 ` [Qemu-devel] " Brian Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=487977679.20070728195405@gmail.com \
    --to=pmiscml@gmail.com \
    --cc=paul.borman@windriver.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).