Il lun 23 giu 2025, 08:53 Markus Armbruster <arm...@redhat.com> ha scritto:
> We end up with two separate ways to do the same job, which is kind of > sad. > > I gather the alternative would be to use generated QAPI visitors for the > generated Rust data types instead of Serde. This would be unusual for > Rust code: Serde exists and works, so reinvent it would be wasteful and > dumb. > My feeling as well. The string visitors have long been a thorn in my side. > > I wish QOM wasn't so annoyingly flexible. I wish a property had to be > of QAPI type (possibly complex). Less headaches. Less boilerplate, > too. > > Almost all QOM properties are. And the few that aren't feel like bad > ideas to me. > Makes sense. On the other hand, from the C point of view I admit that passing a Visitor* or a QObject* to the setter would not be very different—or possibly even a bit more code for the QObject*. Likewise for passing a QObject** on the getter side. So the problem isn't the flexibility... It's using/exploiting it. > * Keep using serde like for commands: in the callback that is invoked by > > object_property_set() do Visitor->QObject->setter (yes that means double > > conversion when the source visitor is and QObject visitor) or for the > > getter case, getter->QObject->Visitor. This has the minimum amount of > code > > added to qapi-gen. > > Recall the callback gets the new property value wrapped in an input > visitor. Whereas a C setter extracts it into some C variable(s), a Rust > setter extracts it into a QObject, which it then passes to Serde for > deserialization into Rust variables. Correct? > Yes. > * Generate a visit_type_*() implementation that emits a Rust struct (i.e. > > one that maps for example 'str' to a String and not a *mut c_char) and > > forgo serde completely. Use this generated implementation everywhere: QOM > > getters and setters, as well as QMP commands. This is how C code works. > > This is the alternative mentioned above. > Yes. > * Generate rust->C (e.g. String->*mut c_char) and C->rust converters from > > qapi-gen; use the existing C visit_type_*() to extract data from visitors > > and then apply said converters to turn the data into a Rust struct, and > > likewise in the other direction. This was the way Marc-André's prototype > > worked. > > Converters between C and Rust data types let us cut at the C data type > instead of at QObject. > > We use the same code up to QAPI-generated C data type and from > QAPI-generated C data type on. > > In between, we work directly with the C data type for properties > implemented in C, and convert to and from the Rust data type for > properties implemented in Rust. > > Correct? > Yes. The simplest such converters convert via QObject. Grossly inefficient > :) > > Marc-André's prototype demonstrates efficient converters can be had. > The question is whether they're worth their keep. > Exactly. What keeps me on the edge is that for QMP the result is still a bit less efficient than straight QObject->Rust via Serde. For the QOM property Visitor->C->Rust is better than Visitor->QObject->Rust, but is it worth the extra amount of code generator? Leaving the code generation business to Serde is appealing and it gets one of the two (QMP) as efficient as it can be. The Serde interface code is pretty much write once and forget, since QObject hasn't changed substantially in 15 years. The qapi-gen code is write once but stays more in the way of other Python code we maintain. On the other hand the Serde code is probably going to be a bit on the impenetrable side, and until someone writes it we don't know if the balance may tilt back towards preferring Marc-André's ideas. Paolo
