On 20/09/2016 10:08, Markus Armbruster wrote: > Peter Maydell <[email protected]> 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.
This is not a big deal. Devices need to be classes, that's enough. >> 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. I think -serial and -net configuration is so pervasive that we have to pass on this requirement. >> (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? The Raspberry Pi board is probably one of the best examples. Its only snag is that one of the devices (hw/arm/bcm2835_peripherals.c) uses serial_hds[]. Paolo
