On Wed, Sep 10, 2025 at 01:05:40PM +0200, Markus Armbruster wrote: > Daniel P. Berrangé <[email protected]> writes: > > On Fri, Aug 08, 2025 at 11:30:32AM +0200, Markus Armbruster wrote: > > > > I don't see 'warnings' as something directly actionable for a user. > > Rather they are messages that I would want to see included in a log > > file that a user attaches to a bug report if they find some behavioural > > problem. If the user understands the warning great, but that isn't a > > requirement. > > > > IOW, while informative warnings is of course better than not, as long > > as the warning message contains sufficient info for the maintainer to > > understand what happened the minimum quality bar is satisfied IMHO. > > That's a low quality bar indeed. Here's mine: > > 1. A warning should make perfectly clear whether this is a bug that > should be reported, or an issue with usage, resources, etc. that can be > ignored, but may help understand future trouble, if any (typically an > ordinary error that wasn't fully handled). Our errors make bug > vs. ordinary error clear. > > 2. A warning of the former kind (bug) should provide information > developers need to start debugging. For errors, we give them a core > dump, source file and line number. For warnings, we currently give them > grep and warm wishes.
Don't understate the value of "grep" :-) It is my #1 tool when I see a string mentioned in bug report, whether that's from error_report or warn_report. What annoys/frustrates me is when the message (whether an eror or warning) lacks the technical details of exactly what failed. ie if the message doesn't substitute in either the errno value, or the strerror string, or equivalent, then it massively reduces the chances of diagnosis unless the bug is easily reproducible. > 3. A warning of the latter kind (not a bug) should at least try to > provide hints that help users diagnose and correct / work around what's > wrong. "warning: failed to WSAEventSelect()" doesn't. "warning: > trouble initializing slirp for user mode networking" might. I agree that the latter is more informative for users, though for developers it might be worse as such a generic message may provide cover for several different low level problems. Neither help me diagnose the problem though if I see them in a bug report though, because neither include the "WSAGetLastError()" value (or its string equivalent). Probably we deserve both. In the case of "Error" objects, we have error_prepend so code can do error_setg(errp, "failed to WSAEventSelect: %s", WSAGetLastError()) and then the caller one or more levels up the stack can do error_prepend(errp, "unable to initialize slirp user mode networking") which becomes useful when we see the final error_report() or equiv. We don't have an error_prepend concept for warnings 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 :|
