Am 20.09.2016 um 10:08 schrieb Markus Armbruster:
> Peter Maydell <peter.mayd...@linaro.org> writes:
>> If we're going to aim for deprecating and eventually removing
>> some of our unmaintained device and board models, it seems to
>> me that a good first step would be to come up with a definition
>> of what our baseline "needs to be at least this good" level is.
>> I'm guessing that ought to include at least "devices are QOM"
>> and "uses vmstate rather than save/load functions".
> Sounds like a start. We can always refine.
> Qdevified devices that aren't fully QOMified are reasonably easy to
> find: search for init() and exit() methods.
> Non-qdevified devices are harder to find. Anything that maps memory or
> wires up interrupts might be a device. If it's done outside QOM
> realize(), chances are it's either wrong or legacy crap.
> In my opinion, legacy crap is much more tolerable when it doesn't have
> any configuration knobs. See also below.
>> (a) are there any other things we want to include?
> A few ideas:
> * Anything configurable needs to be configurable with non-legacy means:
> -machine, -device.
> Counter-example: a board has serial devices that can only be
> configured with -serial. Hmm, almost certainly covered by "devices
> are QOM" already, but it may still be a useful approach to finding
> problematic stuff that is actually relevant.
> * A smoke test exists: can boot at least into firmware with generally
> available bits. Ideally, the bits are in tree, and the smoke test is
> run by "make check". Perhaps too ambitious for the first round, but I
> think it makes sense.
> * A maintainer exists (d'oh): the machine initialization function is
> covered by MAINTAINERS.
>> (b) does anybody feel like writing up a helpful wiki page
>> on how to update old devices, that we can point prospective
>> maintainers at?
>> (In particular I would appreciate the documentation on how to
>> write a state-of-the-art QOMified device as I don't really have
>> a good idea myself...)
> I guess the first step is identifying good examples, and examples of
> stuff that needs work.
> Paolo, Andreas, can you point us to some reasonably QOMified devices?
I see Paolo already replied, so just a few more comments.
(Reminds me that I still have some ColdFire QOM conversions from a KVM
If you want to replace some of the legacy command line options, we need
to finish the work of defining named paths from /machine. Only then (and
when giving all user devices IDs for /machine/peripheral) can you
realistically use qom-set operations for tweaking things in a new way.
Another aspect is that most properties can't be changed any more after
the device is realized. So I would need to finish the deferred
(recursive) realization patchset, for which ordering concerns remained -
we wanted to generate a list of to-be-realized devices and sort them
before starting the realization.
Don't assume PC behavior where -device serial-pci magically replaces the
default device with your customized one, the serial device may be hidden
beneath a Super I/O chipset like on PReP or inside a SoC device.
Similarly we used to have ARM machines where the new -netdev stuff
couldn't be used because the device doesn't get user-added.
One idea once was to extend the by-ID-reference semantics to allow a QOM
path as transparent means of conversion. I don't think we ever
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)