Marc-André Lureau <[email protected]> writes: > Hi > > On Tue, Oct 13, 2026 at 5:56 PM Markus Armbruster <[email protected]> wrote: >> >> Marc-André Lureau <[email protected]> writes: >> >> > Integer built-in types are currently canonicalized to "int" in >> > query-qmp-schema. Consequently, clients cannot distinguish types such >> > as int8, uint64, and size, even though they accept different ranges. >> >> This is by design. >> >> Width and signedness are an implementation detail. We can change them >> freely without affecting syntactic compatibility of the wire protocol. >> >> If we expose them, we can't anymore, and docs/devel/qapi-code-gen.rst >> section "Compatibility considerations" needs an update. >> >> Why would this be useful? Knowing width and signedness narrows down the >> possible values some, but it need not be tight. > > Well, this was just a first step toward a better introspection support > for constaints. I understand the wire format is just json int, but we > may want to express ranges, enumeration of valid values, alignment, > string format etc.. Exposing signdness and width is the basics, and > establishes a pattern for carrying type-level metadata beyond just > "json-type". This enable clients to do proper validation and UI > generation without knowledge of commands and internals.
Let's assume for the sake of the argument we want to do this. How to best communicate constraints to clients is not obvious. Not least because our idea on what constraints exactly we want to communicate is little more than hand-waving so far. Constraints on acceptable values for integer types could be encoded in type names. This is one way to communicate constraints. Whether it's a good way is not obvious. But let's think about it some more. We'd move from the single type name "int" to multiple ones. In theory, existing clients use type name "int" only to lookup the SchemaInfo, then recognize "meta-type": "builtin", "json-type": "int". Splitting up built-in type "int" into several types does not affect such clients as long as the @json-type value remains the same. In practice, Hyrum's law applies, and we'd have to work with client developers to make sure we're not breaking existing clients. Signedness and width are a crude approximation of the actual constraints. I doubt it's useful by itself, and I'm unwilling to commit to a way to communicate constraints just for that. Fortunately, this patch is only losely connected to what your series is about, namely to "associate properties with QAPI schema types". We can simply drop it. If you'd like to work on communicating constraints, we can talk about scope and interface design separately. [...]
