Re: [Qemu-devel] Config file support

["andrzej zaborowski" <balrog@zabor.org>]

On 24/10/06, Rob Landley <rob@landley.net> wrote:
> On Monday 23 October 2006 4:29 pm, Paul Brook wrote:
> > On Monday 23 October 2006 21:01, Rob Landley wrote:
> > > On Sunday 22 October 2006 2:27 pm, Paul Brook wrote:
> > > > I've been considering a machine config file for a while, but haven't
> come
> > > > up with a coherent way of representing everything yet.
> > >
> > > Do you at least have a list of everything that needs to be represented?
> (I
> > > have a list but am fairly certain it's not complete.)
> >
> > Not really. I guess a generic key/value pair is sufficient for most things
> > (base address, model number, etc).
>
> The things are what I was asking about.  Assuming that QEMU has support for
> the appropriate processor type, support for the right bus controller(s), and
> support for various devices that can attach to that bus, what other
> information is needed to completely specify a machine?  (You mention IRQ
> lines and DMA channels...)

I'm pessimistic about machine config file support. I know little about
the PC-like machines in qemu but I've been playing with embedded
(system-on-chip) hw emulation and every new piece of hardware required
changes (even if very small) in the bus or cpu code as well, the
reason being that manufacturers are allowed to do any kind of tricks
in their hardware knowing that it doesn't need to be configurable,
being sold together as a single board. For example chips with totally
contrasting functions (take keypad input and LCD) are allowed to
communicate between themselves for good synchronisation, without
poking the main processor. A different example is a single device
occupying multiple "slots" on a given bus, or multiple busses.

Basically I expect only things that are "pluggable" in the real world
to be practically configurable through something that is not C code.
So for example PCI or USB, but these are already configurable.

>
> I'm still a little fuzzy about basic questions like "How much information is
> in 'processor type'?"  (Does that include cache size?  Floating point
> support?  Has mmu flag?  Are these separate processors with their own names,
> or are they options to a base processor type?)
>
> > The really OTT method is to embed a python interpreter or something and do
> > the machine init that way. I'm not seriously suggesting that though.

A python (or other) interpreter would be cool in place of qemu monitor though :)

Regards,