[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] steps towards deprecation of old boards and devices
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] steps towards deprecation of old boards and devices |
Date: |
Tue, 20 Sep 2016 10:08:33 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
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?