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. > >> So >> (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 Forum session...) 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 implemented that? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
