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

[Andreas Färber]

Am 20.09.2016 um 10:08 schrieb Markus Armbruster:
> Peter Maydell <address@hidden> 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)