On Mon, Sep 14, 2026 at 10:12:17AM -1000, Richard Henderson wrote:
> On 9/14/26 10:04, Daniel P. Berrangé wrote:
> > On Mon, Sep 14, 2026 at 09:30:56AM -1000, Richard Henderson wrote:
> > > On 9/10/26 00:36, Daniel P. Berrangé wrote:
> > > > @@ -161,9 +163,15 @@ static void qom_list_types_tramp(ObjectClass
> > > > *klass, void *opaque)
> > > > ObjectTypeInfo *info;
> > > > ObjectClass *parent = object_class_get_parent(klass);
> > > > + if (data->has_secure &&
> > > > + data->secure != object_class_is_secure(klass)) {
> > > > + return;
> > > > + }
> > > > +
> > > > info = g_malloc0(sizeof(*info));
> > > > info->name = g_strdup(object_class_get_name(klass));
> > > > info->has_abstract = info->abstract =
> > > > object_class_is_abstract(klass);
> > > > + info->has_secure = info->secure = object_class_is_secure(klass);
> > >
> > > Why are you assigning to has_secure here? I thought that was just for the
> > > filter test above.
> >
> > 'data->has_secure/secure' is for the input parameter allowing the
> > QMP client to say whether the returned device list should be
> > filtered based on security status, or include everything (the
> > default).
> >
> > 'info->has_secure/secure' is for the return value reporting to the
> > client whether each device was secure/insecure.
> Still not getting it. I understand info->secure as an output.
> I do not understand info->has_secure as an output.
>
> Unless info->has_secure = true as an output indicates info->secure is valid?
> But in that case, why make them identical.
Since 'secure' is declared as an optional field in QAPI, the
'info->secure' flag will be ignored when serializing to JSON
if 'has_secure' is not set to true.
By setting 'has_secure = secure', it means that the returned
list will include "secure = true" in the JSON, but we will
entirely omit the 'secure = false' field for insecure devices. T
This is essentially a short-cut making the JSON smaller by
omitting the implied default (insecure) value from the JSON.
This was mirroring how the 'abstract' field is handled, where
we don't bother to report 'abstract = false' for types which
are not abstract.
It is also similar to the '-device help' output where we
report "secure" but not "insecure" (the implified default)
The alternative would be to make 'secure' a non-optional field
making 'has_secure' disapppear and including both secure = true
and secure = false in the serialized JSON.
I don't mind much either way, I was just copying how 'abstract'
was handled.
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 :|
