Re: [PATCH v5 13/13] qapi/cxl.json: Add QMP interfaces to print out accepted and pending DC extents

From: Markus Armbruster <armbru@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: fan <nifan.cxl@gmail.com>,
	 Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	 qemu-devel@nongnu.org, linux-cxl@vger.kernel.org,
	 gregory.price@memverge.com, ira.weiny@intel.com,
	 dan.j.williams@intel.com, a.manzanares@samsung.com,
	 dave@stgolabs.net,  nmtadam.samsung@gmail.com,
	jim.harris@samsung.com,  Jorgen.Hansen@wdc.com,
	 wj28.lee@gmail.com,  Fan Ni <fan.ni@samsung.com>
Subject: Re: [PATCH v5 13/13] qapi/cxl.json: Add QMP interfaces to print out accepted and pending DC extents
Date: Wed, 24 Apr 2024 15:12:34 +0200	[thread overview]
Message-ID: <8734ravr99.fsf@pond.sub.org> (raw)
In-Reply-To: <ZedTEa8aktb-kKwt@redhat.com> ("Daniel P. =?utf-8?Q?Berrang?= =?utf-8?Q?=C3=A9=22's?= message of "Tue, 5 Mar 2024 17:14:57 +0000")

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Tue, Mar 05, 2024 at 09:09:05AM -0800, fan wrote:
>> On Tue, Mar 05, 2024 at 04:15:30PM +0000, Daniel P. Berrangé wrote:
>> > On Tue, Mar 05, 2024 at 04:09:08PM +0000, Jonathan Cameron via wrote:
>> > > On Mon,  4 Mar 2024 11:34:08 -0800
>> > > nifan.cxl@gmail.com wrote:
>> > > 
>> > > > From: Fan Ni <fan.ni@samsung.com>
>> > > > 
>> > > > With the change, we add the following two QMP interfaces to print out
>> > > > extents information in the device,
>> > > > 1. cxl-display-accepted-dc-extents: print out the accepted DC extents in
>> > > >    the device;
>> > > > 2. cxl-display-pending-to-add-dc-extents: print out the pending-to-add
>> > > >    DC extents in the device;
>> > > > The output is appended to a file passed to the command and by default
>> > > > it is /tmp/dc-extent.txt.
>> > > Hi Fan,
>> > > 
>> > > Is there precedence for this sort of logging to a file from a qmp
>> > > command?  I can see something like this being useful.
>> > 
>> > This is pretty unusual.
>> 
>> Yeah. I cannot find anything similar in existing code, my initial plan
>> was to print out to the screen directly, however, cannot find out how to
>> do it nicely, so decided to go with a file. 
>> 
>> Is there a reason why we do not want to go with this approach?
>> 
>> > 
>> > For runtime debugging information our strong preference is to integrate
>> > 'trace' probes throughout the code:
>> > 
>> >   https://www.qemu.org/docs/master/devel/tracing.html#tracing
>> 
>> I am not familiar with the trace mechanism. However, I think the
>> approach in this patch may be useful not only for debugging purpose.
>> Although not tried yet, maybe we can also use the approach to set
>> some parameters at runtime like what procfs does?
>
> Please don't invent something new unless you can show why QEMU's existing
> tracing system isn't sufficiently good for the problem. QEMU's tracing
> can dump to the terminal directly, or integrate with a variety of other
> backends, and data can be turned off/on at runtime per-trace point.

Seconded.