[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)