qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] List of files containing devices which have not been QOMified
Date: Fri, 9 Nov 2018 10:31:37 +0000	[thread overview]
Message-ID: <CAFEAcA_L_L-NiqS98P9n4LShHyBBujNrkQXThEgQ0C7nVC86cQ@mail.gmail.com> (raw)
In-Reply-To: <8a4b7981-cc1f-d2a7-2d92-9bf54a4bb42a@ilande.co.uk>

On 9 November 2018 at 10:17, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
> On 06/11/2018 18:43, Peter Maydell wrote:
>
>> I had an idea for how to get a rough list of source files
>> containing devices that haven't been QOMified. The theory
>> is that a pre-QOM device generally has an "init" function
>> which allocates memory for the device struct. So looking in
>> hw/ for files which call g_new*() or g_malloc*() should get
>> us all the non-QOM devices (as well as a pile of false
>> positives, of course).

>> hw/sparc64/sparc64.c
>
> This would appear to be from sparc64_cpu_devinit() which sets up a ResetData
> structure like this:
>
>     reset_info = g_malloc0(sizeof(ResetData));
>     reset_info->cpu = cpu;
>     reset_info->prom_addr = prom_addr;
>     qemu_register_reset(main_cpu_reset, reset_info);

I think the code I saw that looked like a non-QOMified
device was cpu_timer_create().

The ResetData stuff is just working around the fact that
CPUs don't get reset unless the board code does something
to arrange for that to happen, so it's OK. (I would like
us to eventually tackle properly overhauling our approach
to reset, but that's a separate body of work.)

thanks
-- PMM

  reply	other threads:[~2018-11-09 10:32 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-06 18:43 [Qemu-devel] List of files containing devices which have not been QOMified Peter Maydell
2018-11-06 19:16 ` Philippe Mathieu-Daudé
2018-11-06 23:06   ` Peter Maydell
2018-11-07 15:22     ` Philippe Mathieu-Daudé
2018-11-06 19:43 ` Paolo Bonzini
2018-11-06 19:46 ` Paolo Bonzini
2018-11-06 19:51   ` Alistair Francis
2018-11-06 21:23   ` John Snow
2018-11-06 21:26     ` Paolo Bonzini
2018-11-06 23:05   ` Peter Maydell
2018-11-06 23:09     ` Paolo Bonzini
2018-11-07 18:53 ` Palmer Dabbelt
2018-11-09 10:17 ` Mark Cave-Ayland
2018-11-09 10:31   ` Peter Maydell [this message]
2018-11-10 15:20     ` Mark Cave-Ayland
2018-11-12 10:57       ` Peter Maydell
2018-11-09 11:17 ` Gerd Hoffmann
2018-11-09 11:29   ` Gerd Hoffmann
2018-11-09 12:39     ` Thomas Huth
2018-11-09 12:44       ` Peter Maydell
2018-11-09 13:16       ` Paolo Bonzini
2018-11-09 14:03         ` [Qemu-devel] deprecating/removing bluetooth (was: Re: List of files containing devices which have not been QOMified) Gerd Hoffmann
2018-11-12  8:51         ` [Qemu-devel] List of files containing devices which have not been QOMified Thomas Huth

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=CAFEAcA_L_L-NiqS98P9n4LShHyBBujNrkQXThEgQ0C7nVC86cQ@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=mark.cave-ayland@ilande.co.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).