Fix: Handle recent SLE major version codes
Starting in early 2022, the SLE linux version codes changed from the
previous style `5.3.18-59.40.1` to a new convention in which the major
version is a compound number consisting of the major release version,
the service pack version, and the auxillary version (currently unused
from my understanding) similar to the following `5.3.18-150300.59.43.1`[1].
The newer values used in the SLE major version causes the integer
value to "overflow" the expected number of digits and the comparisons
may fail. The `LTTNG_SLE_KERNEL_VERSION` macro also multiplies the
`LTTNG_KERNEL_VERSION` by `100000000ULL` which doesn't work in all
situations, as the resulting value is too large to be stored fully in
an `unsigned long long`.
Example of previous results:
```
// Example range comparison. True or false depending on the value of
// `LTTNG_SLE_VERSION_CODE` and `LTTNG_LINUX_VERSION_CODE`.
LTTNG_SLE_KERNEL_RANGE(5,15,21,150400,24,46, 5,15,0,0,0,0);
// Note: values printed with `%ull`
LTTNG_SLE_KERNEL_VERSION(5,15,21,24,26,1); // 6106486698364570153
LTTNG_SLE_KERNEL_VERSION(5,15,0,0,0,0); // 0
LTTNG_KERNEL_VERSION(5,15,0); // 84869120
// Corrected SLE version codes
LTTNG_SLE_KERNEL_VERSION(5,14,21,150400,24,26); // 14918348902249793914
LTTNG_SLE_KERNEL_VERSION(5,14,21,150400,24,46); // 14918348902249793934
LTTNG_SLE_KERNEL_VERSION(5,15,0,150400,0,0)); // 6971507145825058816
```
`LTTNG_KERNEL_VERSION` packs the kernel version into a 32-bit integer;
however, using that type of packing on the SLE kernel version will not
work well:
* Major: `150400` needs 18 bits
* Minor: may exceed 127, requires 8 bits (eg. `4.12.14-150100.197.148.1`)
* Patch: may exceed 127, requires 8 bits (eg. `5.3.18-150300.59.124.1`)
In this patch, the SLE version is packed into a 64-bit integer
with 48 bits for the major version, 8 bits for each of the minor and
patch versions.
As a result of packing the SLE version into a 64-bit integer,
it is not possible to coherently combine an `LTTNG_KERNEL_VERSION` and
an `LTTNG_SLE_KERNEL_VERSION`. Doing so would require an integer
larger than 64-bits. Therefore, the `LTTNG_SLE_KERNEL_RANGE` macro has
been adjusted to perform the range comparisons using the two values
separately. The usage of the `LTTNG_SLE_KERNEL_RANGE` remains
unchanged, as `LTTNG_SLE_VERSION` is only used inside that macro.
Using the adjusted macros:
```
// Example range comparison. True or false depending on the value of
// `LTTNG_SLE_VERSION_CODE` and `LTTNG_LINUX_VERSION_CODE`.
LTTNG_SLE_KERNEL_RANGE(5,15,21,150400,24,46, 5,15,0,0,0,0);
// Note: values printed with `%ull`
LTTNG_SLE_VERSION(24,26,1); // 1579521
LTTNG_SLE_VERSION(0,0,0); // 0
LTTNG_KERNEL_VERSION(5,15,0); // 84869120
// Corrected SLE version codes
LTTNG_SLE_VERSION(150400,24,26); // 9856620570
LTTNG_SLE_VERSION(150400,24,46); // 9856620590
LTTNG_SLE_VERSION(150400,0,0)); // 9863168000
```
Known drawbacks
===============
It's possible that future releases of SLE kernels have minor or patch
values that exceed 255 (SLE15SP1 has a release using `197`, for example),
requiring an adjustment to using more bits for those fields when
packing into a 64-bit integer.
The schema of multiplying an `LTTNG_KERNEL_VERSION` by a large value
is used for other distributions. RHEL in particular uses
`100000000ULL`, which could lead to overflow issues with certain
comparisons similar to the previous behaviour of
`LTTNG_SLE_KERNEL_VERSION(5,15,0,0,0,0);`.
[1]: https://www.suse.com/support/kb/doc/?id=000019587#SLE15SP4
Change-Id: Iaa90bfa422e47213a13829cdf008ab20d7484cab
Signed-off-by: Kienan Stewart <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>
