[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Machine description as data prototype, take 6
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] Machine description as data prototype, take 6 |
Date: |
Tue, 17 Mar 2009 16:06:23 +0000 |
User-agent: |
KMail/1.9.9 |
> * 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