Markus Armbruster wrote: > Jan Kiszka <jan.kis...@siemens.com> writes: > >> Luiz Capitulino wrote: >>> On Fri, 18 Jun 2010 13:26:27 -0300 >>> Miguel Di Ciurcio Filho <miguel.fi...@gmail.com> wrote: >>> >>>> These commands show the information about active backend network devices. >>>> >>>> Signed-off-by: Miguel Di Ciurcio Filho <miguel.fi...@gmail.com> >>>> --- >>>> qemu-monitor.hx | 105 >>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> 1 files changed, 105 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/qemu-monitor.hx b/qemu-monitor.hx >>>> index 9f62b94..8fc5ed6 100644 >>>> --- a/qemu-monitor.hx >>>> +++ b/qemu-monitor.hx >>>> @@ -1674,6 +1674,111 @@ show the various VLANs and the associated devices >>>> ETEXI >>>> >>>> STEXI >>>> +...@item info netdev >>>> +show information about the current backend network devices >>>> +ETEXI >>>> +SQMP >>>> +query-netdev >>>> +------------ >>>> + >>>> +Each device is represented by a json-object. The returned value is a >>>> json-array >>>> +of all devices. >>>> + >>>> +Each json-object contains the following: >>>> + >>>> +- "id": the device's ID, must be unique (json-string) >>> There were some talking about changing this to 'device. Jan, Markus? >> Only for qdev. Should be a different namespace here. > > Huh? > > We need to point to the NIC here, i.e. we need a unambigous name. > Device ID is fine, but it's optional. Canonical qdev path?
Unless I'm still on the wrong track: 'peer' should point to the front-end, this ID describes the back-end, and that's not a qdev thing. Still, dumping the peer's qdev path along its (optional) ID might be worth a thought. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
