qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] qom: add option -dt-printf wich writes DeviceCl


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH] qom: add option -dt-printf wich writes DeviceClass hierarchy in file
Date: Wed, 13 Jul 2016 18:42:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2

Am 13.07.2016 um 17:30 schrieb goremykin:
> Andreas Färber писал 2016-07-12 18:41:
>> Am 12.07.2016 um 17:33 schrieb address@hidden:
>>> From: goremykin <address@hidden>
>>>
>>> Option -dt-printf 'file' writes Device Tree (DiveceClass hierarchy) to
>>> 'file' using Json format. This helps developers visualize the hierarchy
>>> of DeviceClass and its properties.
>>>
>>> Signed-off-by: Oleg Goremykin <address@hidden>
>>> ---
>>>  include/qom/qom-dt.h |  22 ++++++++
>>>  qemu-options.hx      |  16 ++++++
>>>  qom/Makefile.objs    |   1 +
>>>  qom/qom-dt.c         | 142
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  vl.c                 |   4 ++
>>>  5 files changed, 185 insertions(+)
>>>  create mode 100644 include/qom/qom-dt.h
>>>  create mode 100644 qom/qom-dt.c
>>
>> Hm, apart from some typos I don't quite like the file placement and
>> implementation. Can't you just implement this as a QMP/HMP command and
>> leave the qom/ dirs untouched? Or maybe even extract that info from an
>> external Python script like qom-list etc. do?
> 
> We are developing automatic boards and device templates creation tools.
> It would be better if I get DeviceClass hierarchy without QEMU running,
> but it's unachievable due to implementation of QEMU device registration.
> External Python script is bad because it requires connection with QEMU.
> This script should establish the connection and follow the QMP protocol.
> In my opinion, it's quite complicated way and brings a lot of overhead.
> Unlike QMP/HMP command dt-printf option terminates before creation of
> board. It requires only start QEMU with this option.

You can already get a list of the available devices from the command
line today.

The hierarchy is internal though and not considered ABI. What is the use
case for exposing it? I would rather not want to freeze those
implementation details as stable.

> Where better to place the code? Maybe /util?

Probably not. For HMP there is hmp.c for example, or qdev-monitor.c.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]