Re: [Qemu-devel] steps towards deprecation of old boards and devices

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

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

The trouble with init() methods is how they fail: error_report() &
return -1.  Sucks for QMP: the specific error message from
error_report() goes to stderr, and QMP is left with a rather useless
"Device initialization failed" error.

That's still not a big deal when init() can't fail, but then init() is
trivial to convert to realize(), and I think we got most of those by
now.

>>> 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.

I'm not proposing to get rid of -serial.  I'm proposing to use it as
indicator of old code in need of modernization.  A properly QOMified
serial device should be "configurable with non-legacy means".  Devices
that aren't are probably not QOMified.

Of course, we'll want to be pragmatic.  If half of the boards have a
certain kind of problem, making QEMU threaten deprecation isn't
credible.  It's not even useful.  We'll have to work with active
maintainers to reduce the scope of the problem first.  And for that, we
need to gauge the scope.

>>> (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[].

Yes, but it uses it to configure QOMified devices, doesn't it?

It should be possible to configure these with non-legacy means, at least
in theory.