On Wed, Apr 24, 2024 at 03:12:34PM +0200, Markus Armbruster wrote: > Daniel P. Berrangé <berra...@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....@gmail.com wrote: > >> > > > >> > > > From: Fan Ni <fan...@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): https://lore.kernel.org/linux-cxl/ziafyub6fc9nr...@memverge.com/T/#t Fan
