From: BALATON Zoltan <balaton@eik.bme.hu>
To: Markus Armbruster <armbru@redhat.com>
Cc: Chao Liu <chao.liu@yeah.net>, Chao Liu <lc00631@tecorigin.com>,
pbonzini@redhat.com, peterx@redhat.com, david@redhat.com,
philmd@linaro.org, qemu-devel@nongnu.org
Subject: Re: [PATCH v7 0/1] Optimizing the print format of the QEMU monitor 'info mtree'
Date: Mon, 16 Jun 2025 18:08:00 +0200 (CEST) [thread overview]
Message-ID: <c9fb8902-1be1-2ab3-b926-007933eb6475@eik.bme.hu> (raw)
In-Reply-To: <87h60fd9vv.fsf@pond.sub.org>
[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]
On Mon, 16 Jun 2025, Markus Armbruster wrote:
> Chao Liu <chao.liu@yeah.net> writes:
>
>> On 2025/6/16 13:55, Markus Armbruster wrote:
>>> Chao Liu <lc00631@tecorigin.com> writes:
>>>
>>>> From: Chao Liu <chao.liu@yeah.net>
>>>>
>>>> Hi, all:
>>>>
>>>> After several rounds of discussion, I think that adding a -t option to the
>>>> `info mtree` command, which enables the display of tree-like node characters
>>>> (e.g., +--, |--), is a better approach.
>>>>
>>>> As BALATON Zoltan pointed out, retaining space-based indentation for displaying
>>>> memory region (mr) nodes helps ensure that the output remains easily parseable
>>>> by other programs. This also provides better compatibility with existing tools
>>>> and scripts.
>>>
>>> If people really feed the output of HMP info mtree to parsers, we should
>>> probably provide the information via QMP.
>>
>> Thank you for your helpful advice. I think the next step is to try implementing "info mtree" via QMP first, and then have it called by HMP.
>>
>> I’ve added it to my to-do list, and I’ll try to implement it using QMP in the next phase.
>
> First question before you actually do that: use cases for feeding the
> information to programs? You might have answers already; I'm not on top
> of prior conversations.
My request was to not make the output much wider than it is now as that
would result in broken lines and less readable output. The comment was not
about parsing output but keeping the result fit in not too wide terminals
as 64 bit addresses makes it wide already. Thus replacing spaces with tree
chars is OK with me as long as no new vertical space is added. The first
version of patch increased vertical space. Using ASCII chars was request
from somebody else but that makes the output look less nice so I'm not
sure it worth the change with that. Maybe leaving current output then
adding a separate tree mode with the original line drawing chars could
satisfy all preferences.
Regards,
BALATON Zoltan
prev parent reply other threads:[~2025-06-16 16:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-13 7:49 [PATCH v7 0/1] Optimizing the print format of the QEMU monitor 'info mtree' Chao Liu
2025-06-13 7:49 ` [PATCH v7 1/1] system: improve visual representation of node hierarchy in 'info mtree' output for qemu monitor Chao Liu
2025-06-16 5:55 ` [PATCH v7 0/1] Optimizing the print format of the QEMU monitor 'info mtree' Markus Armbruster
2025-06-16 13:45 ` Chao Liu
2025-06-16 14:44 ` Markus Armbruster
2025-06-16 15:02 ` Chao Liu
2025-06-16 16:08 ` BALATON Zoltan [this message]
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=c9fb8902-1be1-2ab3-b926-007933eb6475@eik.bme.hu \
--to=balaton@eik.bme.hu \
--cc=armbru@redhat.com \
--cc=chao.liu@yeah.net \
--cc=david@redhat.com \
--cc=lc00631@tecorigin.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--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).