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

[Markus Armbruster <armbru@redhat.com>]

Andreas Färber <afaerber@suse.de> writes:

> Am 20.09.2016 um 10:08 schrieb Markus Armbruster:
>> 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.
>> 
>> 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.

Do you think you can work on this?

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

We need to find a way to name onboard devices, so we can configure them.
QOM paths might do.

Our traditional way to configure onboard devices is to deposit
configuration in global variables, where the board can pick it up if it
feels like it.  That's how -serial, -net and so forth work.  Nice when
you don't care about the anatomy of your board.  Not so nice when your
board silently ignores your configuration.  Also not nice: the
connection between configuration and device is rather unobvious.  You
need to find the spot in the code where configuration is picked out of
global variables.  Finally, it doesn't let you configure "unusual" stuff
at all.

If we had means to configure specific onboard devices, we could then
reimplement the legacy options on top: the board describes how they
apply to (named) devices, in one place.  I think that would be easier to
understand.  It would also make rejecting non-sensical configuration
easy.

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

What exactly do you mean by "transparent means of conversion"?