On 20/09/2016 10:08, Markus Armbruster wrote:
> 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.

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


Reply via email to