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

[fan]

On Wed, Apr 24, 2024 at 03:12:34PM +0200, Markus Armbruster wrote:
> 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.
> 

Thanks. 
This patch is removed from the latest version (v7):
ZiaFYUB6FC9NR7W4@memverge.com/T/#t">https://lore.kernel.org/linux-cxl/ZiaFYUB6FC9NR7W4@memverge.com/T/#t

Fan