1

I want to be able to ascertain what kernel is in use across modern, UNIX-derivative OSes.

This appears feasible, considering that utilities like uname exist on multiple OSes with different kernels. However, if we consider the venerable uname to be a usable example, it soon fails at this: it prints “Darwin” on macOS, which isn't the name of the kernel. It's XNU. (macOS is, in effect, the DE running atop the Darwin OS). In contrast, uname on cpe:/o:fedoraproject:fedora:42 prints “Linux”, which is the name of the kernel, rather than the base of the OS (GNU's CoreUtils). That kind of inconsistency renders it unreliable for this.

My goal might seem niche, because it is. However, if I've got a system running macOS, another running Hurd-based Debian, and another running Linux-based Fedora, what tool can I utilise to ascertain the kernel in use? (I suppose I could just look in /boot/efi?)

1
  • 4
    "I suppose I could just look in /boot/efi?" That sounds like definitely the wrong place. Both makes wrong assumptions on the relation between bootloaders and loaded kernels, and wrong assumptions on the prevalence of EFI, and on the accessibility of the EFI system partition across different system. Commented 23 hours ago

2 Answers 2

8

Honestly, especially in the context of diverse operating systems like Hurd, Mac OS/Darwin and Linux:

You'll have to trust the operating system to tell you what the operating system is. Your idea that XNU is the kernel, a sensibly separable part of Darwin, might be nice, and historically pleasant, but I don't see why Darwin (which is the operating system you're interacting with) would implement any function that tells you about that "personal" distinction.

And that's true for other OSes as well.

Good discussion point is Hurd there: You can't really speak of the "Hurd kernel", right, because that's not how microkernel servers responding to system requests would call themselves, but "Mach", hm does that cut it at describing it?

So, either you just say "hm, 'kernel' means different things for different operating systems", which I find fairly self-evident, considering the ranges of monolithic to nearly-micro-kernel OSes you list, and just stick with the reality of it, and use what uname tells you.

Or, you start keeping your own table of mappings ("Darwin means a XNU kernel runs", "Linux means a Linux kernel is running, unless this other test tells us we're running in a Linux emulation on some *BSD", "Linux.*UML means that we're in a user mode Linux kernel, probably running on a Linux kernel?",…) and detectors.

Frankly, I'd go with the former. Since different kernels have nothing in common that you could use to abstract them without knowing the rest of the OS, "give me a string that describes the kernel" seems relatively useless to me: on a Debian kFreeBSD you'd get "FreeBSD" (I guess!), but then when you try to do anything that uses FreeBSD operating system interfaces you'd be meeting problems. Generally, on the weak copyleft kernels, chances are pretty high asking the kernel would return something like "airfrierKernel", which might be a slightly modified NetBSD, or a FreeBSD, or maybe it's a Minix fork? Or is it actually a bit of an overblown Zephyr? Or a system-licensed QNX procnto? There's very little useful information in knowing the kernel name in itself; it's a very human, very non-actionable thing :)

3
  • Thanks for this. I retrospect, I feel foolish for not considering that an OS might not meaningfully distinguish between its kernel and the rest of its OS. (That anecdote about FreeBSD naming makes me angry that it doesn't use rDNS or nested class notation. Would be nice if I could just awk and sed FreeBSD.AirFrierKernel into FreeBSD!!!!!!!!!!) Commented 18 hours ago
  • 1
    @RokeJulianLockhart nothing to be angry about. It's source code. You can modify it however you like it, so people do :) Commented 6 hours ago
  • as a matter of specification, what uname tells you is implementation-defined. It would be spec-compliant for me to run your tool against a uname compiled to give you incorrect information. Of course, it'd also be counter-productive to do so. Commented 6 mins ago
4

From man 1 uname:

Print certain system information.  With no OPTION, same as -s.

       -a, --all
              print all information, in the following order, except omit
              -p and -i if unknown:

       -s, --kernel-name
              print the kernel name

       -n, --nodename
              print the network node hostname

       -r, --kernel-release
              print the kernel release

       -v, --kernel-version
              print the kernel version

       -m, --machine
              print the machine hardware name

       -p, --processor
              print the processor type (non-portable)

       -i, --hardware-platform
              print the hardware platform (non-portable)

       -o, --operating-system
              print the operating system

       --help display this help and exit

       --version
              output version information and exit

Thete's also man 2 uname, if you need the information in a program.

2
  • 4
    The question already mentions uname, and it also mentions that variations across operating environments are an issue, so quoting the GNU man page isn’t particularly useful. Commented 20 hours ago
  • 2
    @StephenKitt, although I didn't actually know of the explicit --kernel-name option, and if I had, might have realised what a/798481 states: that the distinction between kernel and userland isn't always clear. Commented 18 hours ago

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.