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

[Markus Armbruster <armbru@redhat.com>]

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.