Re: [PATCH 14/19] scripts/qapi: generate high-level Rust bindings

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 12/9/25 11:03, Markus Armbruster wrote:
>> * Why is util::qobject::QObject needed?
>> 
>> * NONE is an error value, not a valid QType.  Having such error values
>>    in enums isn't unusual in C.  What about idiomatic Rust?  Even if it's
>>    unusual there, we may elect to do it anyway, just to keep generated
>>    Rust closer to C.  But it should be a conscious decision, not a blind
>>    port from C to Rust.
>
> For QType we don't need to keep it closer, but actually ABI-compatible: 
> QType is defined by QAPI but is used (almost exclusively) by QObject. 
> We use the C version in the QObject bindings, for example:
>
>                  $($crate::bindings::QTYPE_QNULL => break $unit,)?

I see.  Worth a comment.

>> * "Default for QType" is NONE.  In C, it's zero bytes, which boils down
>>    to QTYPE_NONE.
>> 
>> * QTYPE__MAX is a bit of a headache in C.  It's not a valid enum value.
>>    We make it one only because we need to know the largest valid enum
>>    value, e.g. to size arrays, and the easiest way to get that value is
>>    adding an invalid one to the enum.  Same for all the other generated
>>    enums.  Could we avoid it in Rust?
>
> Yes, I think so.
>
>> * C has a file comment of the form
>> 
>>      /*
>>       * One-line description of the file's purpose
>>       *
>>       * Copyright lines
>>       *
>>       * License blurb
>>       */
>> 
>>    I think Rust could use such a comment, too.
>
> Ok.
>
>> * C has built-in types like QType in qapi-builtin-types.h, generated
>>    only with -b.  This is a somewhat crude way to let code generated for
>>    multiple schemas coexist: pass -b for exactly one of them.  If we
>>    generated code for built-in types unconditionally into qapi-types.h,
>>    the C compiler would choke on duplicate definitions.  Why is this not
>>    a problem with Rust?
>
> Because there's better namespacing, so it's okay to define the builtin 
> types in more than one place.  However, do we need at all the builtin 
> types in Rust?  QType is only defined in QAPI to have the nice enum 
> lookup tables, and we can get it via FFI bindings.  Lists, as you say 
> below, are not needed, and they are also a part of qapi-builtin-types.h.
>
> So I think Rust does not need built-in types at all, which I think 
> solves all your problems here (other than _MAX which can be removed).

Let's try this.

>> * The Rust version doesn't have deallocation boilerplate.  Deallocation
>>    just works there, I guess.
>> 
>> * The Rust version doesn't have the List type.  Lists just work there, I
>>    guess.
>
> Yep.
>
>> * The Rust version doesn't have the implicit type q_obj_my_command_arg,
>>    which is the arguments of my-command as a struct type.  C needs it for
>>    marshaling / unmarshaling with visitors.  Rust doesn't, because we use
>>    serde.  Correct?
>
> Commands are not supported at all yet.
>
> Paolo

Thanks!