On Wed, Feb 11, 2026 at 10:43:04AM -0800, Shameer Kolothum Thodi wrote:
> > On Wed, Feb 11, 2026 at 07:14:40PM +0100, Eric Auger wrote:
> > > On 2/11/26 7:07 PM, Nicolin Chen wrote:
> > > > On Wed, Feb 11, 2026 at 08:34:13AM +0000, Shameer Kolothum wrote:
> > > >> + if (local_err == NULL) {
> > > > Does eventq need to rely on !local_err from cmdq?
> >
> > > if local_err is NULL we can safely use it, no? Or maybe I miss your
> > > point. maybe test !local_err directly?
> >
> > Point is: if local_err isn't NULL, why can't we allocate vEVENTQ?
>
> Technically nothing prevents that I guess.
>
> The only thing is we have to call error_report_err() if local_err != NULL
> and then set local_err == NULL before calling alloc_veventq().
Or should we use:
include/qapi/error.h-402-/*
include/qapi/error.h-403- * Append a printf-style human-readable explanation to
an existing error.
include/qapi/error.h-404- * If the error is later reported to a human user with
include/qapi/error.h-405- * error_report_err() or warn_report_err(), the hints
will be shown,
include/qapi/error.h-406- * too. If it's reported via QMP, the hints will be
ignored.
include/qapi/error.h-407- * Intended use is adding helpful hints on the human
user interface,
include/qapi/error.h-408- * e.g. a list of valid values. It's not for
clarifying a confusing
include/qapi/error.h-409- * error message.
include/qapi/error.h-410- * @errp may be NULL, but not &error_fatal or
&error_abort.
include/qapi/error.h-411- * Trivially the case if you call it only after
error_setg() or
include/qapi/error.h-412- * error_propagate().
include/qapi/error.h-413- * May be called multiple times. The resulting hint
should end with a
include/qapi/error.h-414- * newline.
include/qapi/error.h-415- */
include/qapi/error.h:416:void error_append_hint(Error *const *errp, const char
*fmt, ...)
include/qapi/error.h-417- G_GNUC_PRINTF(2, 3);
?
Nicolin
