qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] QEMU configuration files


From: Fabrice Bellard
Subject: Re: [Qemu-devel] QEMU configuration files
Date: Thu, 19 Jun 2008 11:46:16 +0200
User-agent: Thunderbird 2.0.0.5 (X11/20070727)

Paul Brook wrote:
- Machine definitions contain machine parameters and device definitions.
Device definitions are used to create new devices not instanciated in
the hardcoded machine definition such as PCI and USB devices.
...
- Is it worth specifying board specific network controllers as separate
devices (I tried to do that for smc91c111 devices) ? A simpler solution
would be to add new machine parameters to do that.

IMHO the goal should be for most (maybe all) devices to be explicitly instantiated, not just the easy USB/PCI ones. That may require additional work to specify things like IRQ routing and memory ranges.

Good. So you suggest that I go on transforming the remaining network devices into "generic" devices.

In order to keep the compatibility with the current command line options, it will be necessary to add a default network adapter name in each machine description [it would be simpler to avoid being compatible with the current command line options, but I believe most people are against that].

For example there's no real reason why qemu needs to know about most of the the ARM boards I've added (e.g. integrator, versatile, realview and stellaris boards). They all use approximately the same set of modular components, just in connected in different combinations. I suspect the same is true of many of the pxa boards, and proably many ColdFire devices.

If suitable naming for the buses are defined and if the appropriate device classes are created, I believe the current system can be used to describe a complete machine.

One issue is whether/how much it's desirable to decouple the emulated hardware configuration from the host interface configuration. e.g. should we always create N serial ports, regardless of how many -serial options are specified.

This is maybe slightly different between emulating embedded boards and workstation/server class machines. For workstation/server emulation it's entirely reasonable to arbitrarily add/remove serial and network devices from a "PC" machine based on the user config. For embedded SoC devices you tend to want to emulate a fixed number of devices (matching those present on real hardware) and leave them present but disconnected if the user does not specify appropriate net/serial options.

On case where we currently do this is CDROMs. Omitting -cdrom does not remove the cdrom from the machine, it just means an "empty" cdrom drive is created.

My current solution is to keep the machine.serialN and machine.parallelN parameters to avoid changing too much code in the C machine definitions. The user can still disable these implicit devices and explicitly instantiate serial or parallel ports, provided there are generic devices classes for them (which is currently not the case). It could be possible to do something similar to the network and drives devices:

- the command line interface is still backward compatible (i.e. each C machine description gives the necessary information to instantiate default serial or parallel ports) ; - when using configuration files, no serial or parallel ports are instantiated by default and the user must explicitly declare them.

Fabrice.





reply via email to

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