From: "Natalia Fursova" <Natalia.Fursova@ispras.ru>
To: "'Paolo Bonzini'" <pbonzini@redhat.com>,
"'Markus Armbruster'" <armbru@redhat.com>
Cc: "'Andreas Färber'" <afaerber@suse.de>,
'Паша' <Pavel.Dovgaluk@ispras.ru>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qgraph
Date: Tue, 2 Jul 2019 14:44:05 +0300 [thread overview]
Message-ID: <014c01d530cb$73ff1950$5bfd4bf0$@Fursova@ispras.ru> (raw)
In-Reply-To: <4ed45e59-6d7d-a9ea-9af3-7ec336c7ec3d@redhat.com>
Hi there again!
Thank you for your answers, I have new question.
I want to identify PCI devices (e.g. network cards) and observed one strange thing. I use qmp command "qom-list-type" and build tree from it output. Some items don't have parent and don't give information about themselves. E. g. "e1000-base". It has three children and it belongs to PCI devices, but I can't know it, cuz command "qom-list-properties" returns empty message.
There is no information about "e1000-base" in "qom-list-type" output. It is referenced only as a parent for network cards.
Is it ok? Maybe is there other way for get information about all PCI devices?
Best regards,
Natalia
-----Original Message-----
From: Paolo Bonzini [mailto:pbonzini@redhat.com]
Sent: Tuesday, June 11, 2019 4:45 PM
To: Markus Armbruster
Cc: Natalia Fursova; Andreas Färber; 'Паша'; qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qgraph
On 11/06/19 15:39, Markus Armbruster wrote:
>> Right, and we should move more towards class-based properties so that
>> the dynamic nature of QOM is only used for the bare minimum needed (e.g.
>> memory regions).
> What are we doing to make new code conform to that?
>
> What are we doing to update existing code?
Almost nothing and completely nothing. :(
Paolo
next prev parent reply other threads:[~2019-07-02 11:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5cf62de9.1c69fb81.66fc.8f4fSMTPIN_ADDED_BROKEN@mx.google.com>
2019-06-04 15:06 ` [Qemu-devel] qgraph Paolo Bonzini
2019-06-05 12:34 ` Natalia Fursova
[not found] ` <5cf7b6e6.1c69fb81.1cdca.e260SMTPIN_ADDED_BROKEN@mx.google.com>
2019-06-05 13:07 ` Paolo Bonzini
2019-06-05 14:22 ` Natalia Fursova
2019-06-10 9:53 ` Natalia Fursova
2019-06-10 11:57 ` Andreas Färber
2019-06-10 12:03 ` Paolo Bonzini
2019-06-10 13:28 ` Andreas Färber
2019-06-10 13:52 ` Paolo Bonzini
2019-06-10 16:12 ` Andreas Färber
2019-06-10 16:18 ` Paolo Bonzini
2019-06-11 8:56 ` Markus Armbruster
2019-06-11 10:31 ` Paolo Bonzini
2019-06-11 13:39 ` Markus Armbruster
2019-06-11 13:44 ` Paolo Bonzini
2019-07-02 11:44 ` Natalia Fursova [this message]
2019-07-02 15:26 ` Markus Armbruster
2019-07-03 8:19 ` Natalia Fursova
[not found] ` <5d1b4524.1c69fb81.ddba5.77bdSMTPIN_ADDED_BROKEN@mx.google.com>
2019-07-02 11:54 ` Peter Maydell
2019-06-11 13:51 ` Andreas Färber
2019-06-04 8:37 Natalia Fursova
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='014c01d530cb$73ff1950$5bfd4bf0$@Fursova@ispras.ru' \
--to=natalia.fursova@ispras.ru \
--cc=Pavel.Dovgaluk@ispras.ru \
--cc=afaerber@suse.de \
--cc=armbru@redhat.com \
--cc=pbonzini@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 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.