On Wed, Feb 18, 2026 at 10:52:07AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé <[email protected]> writes:
>
> > There are three general patterns to QEMU log output
> >
> > 1. Single complete message calls
> >
> > qemu_log("Some message\n");
> >
> > 2. Direct use of fprintf
> >
> > FILE *f = qemu_log_trylock()
> > fprintf(f, "...");
> > fprintf(f, "...");
> > fprintf(f, "...\n");
> > qemu_log_unlock(f)
>
> Real code needs to check @f or risk crashing. Shouldn't we show that
> here?
Yes, we should really.
> > 3. Mixed use of qemu_log_trylock/qemu_log()
> >
> > FILE *f = qemu_log_trylock()
> > qemu_log("....");
> > qemu_log("....");
> > qemu_log("....\n");
> > qemu_log_unlock(f)
> >
> > When message prefixes are enabled, the timestamp will be
> > unconditionally emitted for all qemu_log() calls. This
> > works fine in the 1st case, and has no effect in the 2nd
> > case. In the 3rd case, however, we get the timestamp
> > printed over & over in each fragment.
> >
> > One can suggest that pattern (3) is pointless as it is
> > functionally identical to (2) but with extra indirection
> > and overhead. None the less we have a fair bit of code
> > that does this.
> >
> > The qemu_log() call itself is nothing more than a wrapper
> > which does pattern (2) with a single fprintf() call.
>
> qemu_log_trylock()'s lock is recursive. Worth a comment? Not sure.
Sure.
> > Fixes: 012842c07552 (log: make '-msg timestamp=on' apply to all qemu_log
> > usage)
> > Reported-by: Richard Henderson <[email protected]>
> > Signed-off-by: Daniel P. Berrangé <[email protected]>
>
> Reviewed-by: Markus Armbruster <[email protected]>
>
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
