From: Blue Swirl <blauwirbel@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling
Date: Mon, 31 Aug 2009 18:23:52 +0300 [thread overview]
Message-ID: <f43fc5580908310823h3cdc5c0wbf805a16a66f0bf7@mail.gmail.com> (raw)
In-Reply-To: <4A9B85E5.8040902@redhat.com>
On Mon, Aug 31, 2009 at 11:12 AM, Gerd Hoffmann<kraxel@redhat.com> wrote:
> Hi,
>
>> Add info command registration to the API and make some devices use it.
>
> Jumping in here with a more general comment ...
>
> I think right now we have _way_ to much register_something functions.
> IMHO qdev allows us to kill off most of them. We can stick function
> pointers (also VMstate pointers) into DeviceInfo instead of registering
> callbacks.
Good idea. I wish reset could be handled also with a structure.
> Short-term (while we are in the "convert-drivers-to-qdev" phase) that will
> just move the register calls from the driver code to generic qdev code.
>
> Long-term we hopefully can kill the register calls altogether and walk the
> qdev device tree instead.
So at this stage, the registration function should take a structure
argument but later it would be sucked into qdev?
>> User visible monitor commands change: 'info' is replaced by 'dev_info'
>> and also the parameter name may change, for example 'pic' becomes
>> 'i8259.state'.
>
> Hmm, i8259 isn't converted to qdev yet, so the route outlined above above
> will not work (yet) for this device ...
There is also no qdev for pc.c. Maybe there should be one qdev for
each board? The higher level could set up common things like system
reset signal, memory, drives etc. Maybe even PCI.
next prev parent reply other threads:[~2009-08-31 15:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-29 14:06 [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling Blue Swirl
2009-08-31 8:12 ` Gerd Hoffmann
2009-08-31 15:23 ` Blue Swirl [this message]
2009-09-01 7:54 ` Gerd Hoffmann
2009-09-01 16:21 ` Blue Swirl
2009-09-02 6:35 ` Gerd Hoffmann
2009-09-02 14:41 ` Blue Swirl
2009-09-02 16:42 ` Gerd Hoffmann
2009-09-02 17:53 ` Blue Swirl
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=f43fc5580908310823h3cdc5c0wbf805a16a66f0bf7@mail.gmail.com \
--to=blauwirbel@gmail.com \
--cc=kraxel@redhat.com \
--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).