Re: recommendations for handling Hyper-V version number

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On a Wednesday in 2020, Matt Coleman wrote:
Hello again,

Hyper-V version numbers are not compatible with the encoding used in
virParseVersionString:
https://gitlab.com/libvirt/libvirt/-/blob/master/src/util/virutil.c#L246

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.

Is the output of virParseVersionString stored on disk at any point?
Would changing its output type from unsigned long to unsigned long long
cause any compatibility issues? That would allow “minor” and “micro” to
be up to 6 digits each and would be a quick, easy change.


virParseVersionString is just an internal helper, those can be changed
at will if you don't break existing users.

The problem here is the virConnectGetVersion public API - we cannot
alter its signature.

One solution would be to introduce a new API (that possibly returns a
string), but it will take time until apps start using it.

Jano

Thanks,
Matt


Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux