Hello Paul,
Friday, July 27, 2007, 12:25:13 PM, you wrote:
> 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 c
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_ge
-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 a
Hi,
On 26/07/07, Paul Borman <[EMAIL PROTECTED]> wrote:
QEmu Target Configuration - I would like to define a configuration
file syntax (I cannot help but think back to my BSDi days and the BSD/
OS kernel configuration file) that would define the hardware from the
outside. Device drivers would e
On Thursday 26 July 2007 18:34:36 Paul Borman wrote:
> Paravirtualization - I have written a "device driver" for QEmu that
> allows the guest system to essentially make function calls right into
> the host (dealing with data representation, etc). A prime example
> for use of this is OpenGL.
Paul Borman wrote:
> Greetings,
>
> I have been working with QEmu for a few months now at Wind River. I am
> sure many of you already know Jason Wessel and Alex deVries who championed
> QEmu as a tool for our Linux product. It is my goal to demonstrate the
> power of QEmu for embedded software
Greetings,
I have been working with QEmu for a few months now at Wind River. I
am sure many of you already know Jason Wessel and Alex deVries who
championed QEmu as a tool for our Linux product. It is my goal to
demonstrate the power of QEmu for embedded software development
(excuse me,
