On Wed, Feb 07, 2024 at 10:06:46AM +0100, Alice Frosi wrote: > Hi everyone, > > I would like to bring up a possible issue with the libvirt-go-xml-module > and request your advice. > > We are considering using libvirtxml [2] as an alternative of the custom > types for the libvirt schema in KubeVirt [1]. > Nonetheless, KubeVirt makes an effort to adhere to Kubernetes best > guidelines. One thing I've noticed, though, is that libvirtml consistently > uses uint or int rather than uint32 or int32. This is in opposition to the > primitive types that Kubernetes [3] recommends; in fact, KubeVirt uses them > in the schema.go [4]. I sure spotted several uses of (u)int in there :) > Would it be possible to align the libvirtxml go library to the Kubernetes > conventions? Since this library is all about handling XML and doesn't talk at all with the underlying C library, I guess it would be possible to introduce explicit sizing for all struct members. I don't think we can do that without breaking API though. Another topic entirely would be whether the same is possible for the main binding. In that case, the underlying C library dictates the types, so I'm not sure we could change them at the Go level even if we wanted to. I know that you're not currently asking for this, I'm just trying to consider the full picture. Taking a step back, the guidelines say All public integer fields MUST use the Go int32 or Go int64 types, not int (which is ambiguously sized, depending on target platform). Internal types may use int. As long as KubeVirt doesn't use int for its own public types, it shouldn't matter what libvirtxml does, as it's only used internally. Is that not the case? -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
