Re: [Qemu-devel] Machine description as data prototype, take 6

[Paul Brook]

> * The memory driver is PC-specific.  It should be generic and
>   data-driven, but getting there isn't quite as easy as it sounds.
>   Memory (and sometimes even holes) need to be allocated in just the
>   right order to ensure guest physical address equals host offset for
>   certain memory ranges.

This is a bug elsewhere and should be fixed there.

> +/*
> + * Device life cycle:
> + *
> + * 1. Configuration: config() method runs after parent's.  It should
> + * initialize the device's private data from its configuration
> + * sub-tree.  It may edit the configuration sub-tree, and may declare
> + * initialization ordering constraints with tree_require_named().
> + * 2. Initialization: init() method runs after parent's and after that
> + * 3. Start: start() method runs, order is unspecified.

Feels like there's at least one too many callbacks here.

The "may edit the configuration sub-tree" also sounds wrong. Devices shouldn't 
be interacting with the config tree directly, they should just be 
requesting/exposing features. This should also mean we shouldn't need manual 
dependencies because all device interaction is explicit.

Possibly this is a bit confused because you've still got all the device code 
lumped in the same file. It's hard to identify hacks for PC bits you've not 
implemented yet, machine/device independent code, per-device code, and 
hardcoded tree generation in lieu of an actual config file reader. Using ugly 
wrappers round the legacy interface doesn't help, especially for PCI devices 
where we already have an abstraction layer.

Paul