On Thu, Sep 24, 2020 at 06:43:56PM -0400, Matt Coleman wrote: > >> For example, the Windows Server 2016 Hyper-V version is 10.0.14393.0, > >> so its “micro” is over 14 times larger than the encoding allows. > >> > >> My current workaround is to truncate it to something that works (E.G. > >> 10.0.143), but that's clearly less than ideal. > > The problem here is the virConnectGetVersion public API - we cannot > > alter its signature. > I hadn’t realized this was exposed by the public API. > > Since the API can’t change, should I update my code to only output > major.minor instead of truncating micro to an incorrect/misleading > value? > > The downside of this is that Microsoft has referred to Windows 10 as > “the last version of Windows” and Hyper-V versions are the same as the > OS’s kernel version. So, this would result in libvirt’s Hyper-V driver > reporting version 10.0 until Microsoft reconsiders that approach. Our current encoding scheme allows 1000 for each part of the version number. Realistically the major and minor version numbers are unlikely to exceed 99 respectively. IOW we could stuff both the hyper-v major + minor version digits into the libvirt major digits. Then we can split the hyperv micro digits across the libvirt minor + micro. ie pack it using version = (major * 100,000,000) + (minor * 1,000,000) + micro If any libvrt apps are trying to reverse parse this and turn it back into dotted values, it is going to look wierd, but at least we won't be discarding information. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
