qemu-devel
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]