Kernel name

[dtolnay]

Context: I am working on porting a project off of sys-info because it is unmaintained and does not work on Android. I am considering using sysinfo.

The sys-info crate provides a pair of functions os_type() and os_release(). The pair of values from these functions (for example "Linux" "6.8.0-48-generic", or "Darwin" "24.1.0") is a useful aggregation for identifying kernel-specific bugs. They are used for this purpose by https://crates.io/crates/bugreport.

As seen in #1416, sysinfo's existing suite of system name/version methods (name(), kernel_version(), os_version(), long_os_version(), distribution_id()) is not conducive to aggregating bugs by kernel version.

• If we aggregate by only kernel_version(), then bugs from 2 completely unrelated kernels with the same version could end up bucketed together. Maybe this doesn't happen right away because contemporary Linux versions start with a single-digit integer and contemporary Darwin versions start with a double-digit integer and Windows does its own thing, but are we sure about other systems? How many years before the Linux version range overlaps the Darwin version range supported by Rust?

• If we aggregate by kernel_version() + any of the other four functions, the bucketing is too fine because bugs from the same kernel end up in different buckets. For example 2 different Android device models using the same kernel, or 2 different Linux distributions using the same Linux version.

• If we aggregate by anything not involving kernel_version(), none of the other options identify the kernel version.

It would be useful to have a kernel_name() where the tuple of kernel_name() + kernel_version() identifies a particular release of one kernel.

For this use case, it would be acceptable to prioritize names that are meaningful to technical humans over technical accuracy, for example when it comes to "Darwin" vs "XNU", or "Windows" vs "NT".

[GuillaumeGomez]

Sounds good to me and it also seems like you know what you want so feel free to send a PR. If you don't have a system for the implementation, I'll implement that so no need to worry about it.

[dtolnay]

As I looked into this more, one complication is what to return on Windows. On Windows the System::kernel_version() returns something like "20348" (tested on a windows-latest GitHub Actions runner). https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions#Server_versions refers to this as the "Build number", which I guess maybe uniquely determines a kernel version, but maybe not. In https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info and https://support.microsoft.com/en-us/topic/january-9-2024-kb5034129-os-build-20348-2227-6958a36f-efaf-4ef5-a576-c5931072a89a Microsoft refers to "OS build 20348" and "OS Build 20348.2227". So it's possible that having a System::kernel_name() that returns "OS build" would be the friendliest behavior for the purpose of someone doing println!("kernel: {} {}", System::kernel_name(), System::kernel_version()). Or maybe it would be better to scrap kernel_name() and provide a long_kernel_version() intended for disambiguating among distinct kernels with the same version number, and returns "OS build 20348" on Windows.

The sys-info crate is not a useful guide here because it never fixed their equivalent of #410 (FillZpp/sys-info-rs#86). So sys_info::os_type() and sys_info::os_release() return "Windows" and "6.2.9200" respectively, which is neither a kernel version nor OS version nor build number.

[GuillaumeGomez]

So to sum it up, kernel_name() would return "Windows", kernel_version() would return "20348" and kernel_long_version() would return "Windows OS build 20348". I suppose it can be done following the same scheme on other platforms, if so sounds all good to me. Thanks for the extra details, it's really interesting (learned quite a few things!). Just need to precise in the docs of kernel_long_version() that it's not just kernel_name() + kernel_version() but provides extra information.