[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 13/13] qapi/cxl.json: Add QMP interfaces to print out acce
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH v5 13/13] qapi/cxl.json: Add QMP interfaces to print out accepted and pending DC extents |
Date: |
Tue, 5 Mar 2024 17:14:57 +0000 |
User-agent: |
Mutt/2.2.12 (2023-09-09) |
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.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
- [PATCH v5 10/13] hw/mem/cxl_type3: Add dpa range validation for accesses to DC regions, (continued)