All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "QEMU Developers" <qemu-devel@nongnu.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] steps towards deprecation of old boards and devices
Date: Tue, 20 Sep 2016 10:08:33 +0200	[thread overview]
Message-ID: <87k2e7uh6m.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA_jncWXix0GoCkHqaAE3m0iLWrkKZFch9OfxsERK3tg=A@mail.gmail.com> (Peter Maydell's message of "Tue, 13 Sep 2016 18:09:46 +0100")

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?

  reply	other threads:[~2016-09-20  8:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-13 17:09 [Qemu-devel] steps towards deprecation of old boards and devices Peter Maydell
2016-09-20  8:08 ` Markus Armbruster [this message]
2016-09-20  8:22   ` Paolo Bonzini
2016-09-20 11:04     ` Markus Armbruster
2016-09-20 11:48       ` Paolo Bonzini
2016-09-20 13:53         ` Markus Armbruster
2016-09-20 11:44   ` Andreas Färber
2016-09-20 13:50     ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k2e7uh6m.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=afaerber@suse.de \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.