Re: [Qemu-devel] QEMU configuration files

[Fabrice Bellard <fabrice@bellard.org>]

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.