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

[andrzej zaborowski]

On 27/07/07, Paul Borman <address@hidden> wrote:
> The platform I started with was ppc_prep :-)
>
> So, is Python already part of qemu?  Personally, I would have a goal
> that the definition of a device would be simple enough that there
> would be no reason to have anything more complicated than a simple
> text file.  While I would not suggest that the BSD config file syntax
> should be used, I do think it is instructive.

The python thing is not in qemu and is (I think) a long term project
in not much sync with qemu now, but I don't know the details.

>
> It has a section for defining macros, really, the standard name/value
> pairs
>
>         options         KTR                     # kernel wraparound trace
> buffer support
>         options "KTR_SIZE=32768"        # trace buffer in bytes (def=8K)
>         options "KTR_COMPILE='~0'"      # compile in all traces
>         options "KTR_MASK=0"            # but turn none of them on
>
> Clearly there would be cleaner ways to specify this for QEmu
>
>         set memory_size 0x10000000
>
> There is also a section that specifies the various devices.  Here is
> a snippet of a kernel for an embedded PPC board I used to work on:
>
>
>         # main (on-board io) bus
>         obio0   at root
>         pci0  at obio0
>
>         # COM ports
>         # Flags are 0xF00000 for fifo flags F; see com(4).
>         # Default is 0; 1, 2, 3, 4 set receive fifo trigger to 1, 4, 8, 14;
>         # 9 ignores the FIFO on 16550/16550AF.
>         com0    at obio? addr "0xff600300" irq 3
>         com1    at obio? addr "0xff600400" irq 4
>
>         # Crystal Semiconductor Ethernet
>         ce0     at obio? addr "0x7fe00c00" irq 24
>
>         # Disk On Chip 2000 driver
>         dc0    at obio? iomem "0x800d0000" iosiz 0x2000
>
> This particular syntax specifies several things:
>
> 1)  The devices in a generic way
> 2)  How devices are connected
> 3)  The order to search for the devices
>
> Again, QEmu would need something slightly different, but at least
> this demonstrates how a similar problem has been previous solved.
>
> There are also pseudo devices
>
>         pseudo-device   loop
>         pseudo-device   pty
>         pseudo-device sl      1
>
> QEmu might be able to treat pseudo and "physical" devices the same,
> or maybe keeping them independent would be good.
>
> 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.  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)

I think python or other scripting language are a much better idea than
a custom syntax with only variables and static content. I would hate
to write 121 lines to set up initial states of the 121 gpios present
in pxa-based machines, I would use a loop.

In my experience embedded machines even those with very similar
capabilities and coming from the same manufacturer have huge hardware
differences between models. My experience is only with ARM. The common
parts between the different ARM-based computers are usually only the
CPU (which fortunately embeds many peripherals) and if there's an
external chip onboard that two devices use in common then it usually
is wired differently or there are other quirks that will force you
dirty your hands in C code and rebuild (which doesn't really take
significantly more time than editing a config file which is loaded in
runtime). Take as an example a peripheral that has one of the signals
connecting it with the cpu/bus, inverted/pulled up/unconnected, it
would be very hard to make a simple text syntax that accounts for
that, and python might potentially do it without much pain (this
example is a very usual case between PDAs).

Regards