On Wed, Sep 24, 2025 at 09:06:55AM +0200, Markus Armbruster wrote: > Daniel P. Berrangé <berra...@redhat.com> writes: > > > On Tue, Sep 23, 2025 at 04:28:42PM +0200, Markus Armbruster wrote: > >> Daniel P. Berrangé <berra...@redhat.com> writes: > >> > >> > Some code makes multiple qemu_log calls to incrementally emit > >> > a single message. Currently timestamps get prepended to all > >> > qemu_log calls, even those continuing a previous incomplete > >> > message. > >> > > >> > This changes the qemu_log so it skips adding a new line prefix, > >> > if the previous qemu_log call did NOT end with a newline. > >> > > >> > Reported-by: Richard Henderson <richard.hender...@linaro.org> > >> > Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
snip > > What I didn't realize was that the expectation is to call > > qemu_log_trylock() (which returns the "FILE *" target) and > > then you can ignore the "FILE *" and just call qemu_log() > > repeatedly, and finally call qemu_log_unlock(FILE *) when > > done. > > > > https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/strace.c?ref_type=heads#L4396 > > I can see the qemu_log_trylock() / qemu_log_unlock() bracket. But the > code within doesn't work the way you describe: it uses fprintf(f, ...). > > If it did ignore @f and call qemu_log(), qemu_log() would > qemu_log_trylock() again, taking the RCU read lock and the flockfile() > lock on @f recursively. Should work. > > > This is a slightly wierd API design, > > More seriously: entirely undocumented. The only hint is the presence of > qemu_log_trylock() and qemu_log_unlock(). I'm including a new patch that starts some API docs for the log APIs. 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 :|
