[agorouvein-rgb]

[AI generated] — drafted with Claude, reviewed, tested, and debugged by me on real hardware/VMs at every step. See the "How this was built" note at the bottom for full transparency.

Summary

Adds a new src/sunos/ backend (originally src/openindiana/, renamed since the backend is generic across illumos distributions and Solaris, not OpenIndiana-specific) implementing Shared, Cpu, Mem, Net, and Proc data collection against illumos-native APIs, with optional support for Solaris 10 x86. This backend started as a copy of src/freebsd/, with every FreeBSD-specific mechanism (kvm(3), sysctl(3), devstat(3)) replaced by illumos equivalents:

• CPU stats: kstat(3KSTAT) cpu_stat per-core counters, discovered by walking the live kstat chain rather than probing instance numbers 0..N-1 (CPU ids are not guaranteed contiguous or zero-based — confirmed on SPARC, where a 64-CPU system reported ids 64-127)
• CPU hardware name: pulled from the cpu_info kstat (brand on x86, falling back to implementation elsewhere), then cleaned up the same way upstream's Linux backend does — strips boilerplate (Intel(R), Core(TM), a CPU @ x.xxGHz suffix, etc.) down to just the model name
• Memory: kstat unix:system_pages + ZFS ARC size (kstat zfs:arcstats), used to derive used/available/cached the way Linux/FreeBSD treat page cache
• Swap: native swapctl(2) — no kvm handle required
• Filesystem enumeration: getmntent(3C) reading /etc/mnttab, filtering out pseudo-mounts (vmblock, vmhgfs, etc.)
• Disk I/O: kstat_io_t enumeration by ks_class=="disk"
• Network: kstat per-link rbytes64/obytes64, looked up directly by interface name (module "link", class "net"). Interface enumeration uses SIOCGLIFCONF rather than getifaddrs(), which doesn't exist on Solaris 10.
• Process enumeration: /proc/<pid>/psinfo (psinfo_t), replacing kvm_getprocs()/kvm_getargv()
• Per-process I/O: /proc/<pid>/usage (prusage_t). Solaris/illumos's per-direction counters (pr_inblk/pr_oublk) are a long-documented dead end — they don't reliably track actual I/O volume regardless of platform or workload — so pr_ioch (a combined read+write character count) is used instead; see Known limitations below.

Also includes portability fixes to shared, non-platform files:

• src/btop.cpp: extends the existing pthread_join() fallback (already used for __APPLE__/__OpenBSD__/__NetBSD__) to __sun, since pthread_timedjoin_np() is a GNU/glibc extension unavailable on illumos.
• src/btop.cpp: fixes a crash on terminal resize. signal() has one-shot (System V) semantics on illumos/Solaris — handlers reset to default after their first delivery. btop uses SIGWINCH/SIGUSR1 to interrupt its input loop, so a second resize (or a second Ctrl-C/Ctrl-Z) during a session could kill the process outright, with no core dump or log entry. Signal handlers on this platform are now installed via sigaction() for persistent, BSD-style semantics. This affected every illumos/Solaris build, not just Solaris 10.
• src/sunos/btop_collect.cpp: the file-local namespace fs = std::filesystem; alias is renamed to btop_fs, since native Solaris's <sys/buf.h> (pulled in transitively by some of the headers this backend uses) declares its own fs at file scope and collides with it. illumos doesn't hit this, which is why it wasn't caught earlier.
• Makefile: adds a sunos PLATFORM_DIR block matching the existing per-platform pattern, linking -lkstat -lsocket -lnsl. Source-file discovery now uses GNU Make's built-in $(wildcard ...) instead of shelling out to find -maxdepth, which native Solaris's find doesn't support. Thread count detection now tries psrinfo first, falling back to getconf NPROCESSORS_ONLN only if that's empty, since the latter alone has been reported as unrecognized on at least one native Solaris configuration (silently serializing the build). -static-libstdc++ is no longer forced by default — Oracle Solaris ships no static libstdc++ at all — and is now opt-in via S10=true (see below), which is the only case that actually needs it.

Solaris 10 x86 support (optional, S10=true)

Solaris 10 has no C++23-capable compiler, so binaries are cross-built on an illumos system with a modern GCC and run on Solaris 10 itself. That requires a small number of libc functions Solaris 10 lacks (mostly POSIX 2008 locale functions, plus a few small helpers like clock_gettime/nanosleep, which live in librt rather than libc there). These are provided by an optional compatibility shim, src/sunos/s10compat.c, compiled and linked in only with S10=true; the default sunos build doesn't touch it. It's inert unless explicitly requested.

Known limitations

• ZFS per-dataset disk I/O is not separated; all physical disk I/O is attributed to the root (/) mountpoint, since illumos ZFS mounts report the dataset name rather than a physical device path in /etc/mnttab. True per-dataset attribution likely requires illumos's per-dataset ZFS kstats, not yet investigated.
• pr_psargs truncates long command lines to PRARGSZ (~80 chars); full argv reconstruction via libproc's proc_arg_grab() is a possible follow-up.
• CPU temperature and battery reporting are stubbed (return empty/false/no-op), not yet implemented.
• Per-process I/O (shown when pressing Return on a process) shows a single combined read+write total in IO/R; IO/W is intentionally left blank rather than a misleading 0 Byte, since Solaris/illumos has no reliable way to report the two directions separately (see above).
• The CPU hardware name has only been verified against real Intel and virtualized QEMU brand strings; the cleanup logic hasn't been checked against AMD or real SPARC implementation strings, so minor cosmetic artifacts (e.g. a stray trailing character) are possible there.
• Mouse input requires a terminal that reports the SGR (1006) mouse protocol; older terminals (including some shipped with Solaris 10) only speak the legacy X10 protocol, so mouse clicks/scroll won't register there. Keyboard navigation is unaffected.

Testing

Built and tested in a VirtualBox VM running OpenIndiana Hipster 2026.04, GCC 14.3.0, and on bare metal (Acer Aspire V5-571, same OI release, using the built-in Realtek RTL8111 Ethernet as rge0). Bare-metal testing included running btop continuously in a MATE Terminal session while connecting in over SSH from a separate OI VM and running a package install (pkg install fastfetch), exercising real CPU, disk, and network activity end-to-end rather than synthetic load. (Aside, for anyone else with this model: the built-in Atheros AR9462 wifi is not supported by illumos's arn driver, which only covers AR9280/9281/9285 — Ethernet works fine.)

Solaris 10 (1/13, x86, 64-bit kernel) tested separately, cross-built from the OpenIndiana host per the S10=true process above.

All of Peter Tribble's review feedback (thank you again) has been addressed and tested, including a retest on his own hardware:

• CPU panel on SPARC (contiguous-id assumption) — fixed by walking the live kstat chain instead of probing instance numbers; confirmed working by Peter on a native, natively-compiled Solaris 11.4 SPARC system (T8-1, 64 cores, ids 64-127) — screenshot below shows all 64 cores populated correctly.
• fs/sys/buf.h collision on native Solaris — fixed, renamed to btop_fs; confirmed by the same native Solaris 11.4 build.
• find/getconf NPROCESSORS_ONLN build portability — fixed; confirmed by the same native Solaris 11.4 build.
• -static-libstdc++ forced unconditionally — now opt-in, off by default, only added for the Solaris 10 cross-build (S10=true); dropping it by default is what let the native Solaris 11.4 build succeed.

A second reviewer additionally caught that the per-process IO/R and IO/W fields were always blank (dead code left over from the FreeBSD-derived backend's macOS-originated stub) and that the CPU box showed no hardware name. Both are now implemented per the Summary above and confirmed working on OpenIndiana (VM and bare metal, including sustained raw-device I/O to verify pr_ioch actually tracks real activity).

Also tested on OmniOS (a QEMU VM, vioif0/virtio networking) by a tester from a retro-computing community, confirming the backend works on a second illumos distribution beyond OpenIndiana — different hypervisor, different NIC driver, different userland (SMB/NFS services running). Screenshot below. This was also an unplanned but useful test of the CPU-name cleanup logic against a completely different brand-string shape (QEMU Virtual CPU version 2.5), which it handled correctly.

Still not tested: SmartOS, and native (non-cross-built) compilation on Solaris 10, which has no C++23-capable compiler and so isn't expected to support a native build at all.

How this was built

I don't have a C++ background, but I am a software tester with 30+ years of experience in the software industry. I worked through this interactively with Claude (Anthropic's AI) over several sessions: I ran every command and test on my actual VMs and hardware, verified every kstat/swapctl/psinfo field against real system output before any of it went into the actual source file, and traced/fixed real bugs along the way (e.g. the ZFS-dataset I/O attribution limitation above was a design decision I made once we hit it, not something guessed at; the resize crash was found and root-caused by reproducing it with truss, tracing it to signal()'s platform-specific semantics, and confirming the fix against the actual signal delivery behavior; the per-process I/O fix went through two iterations after the first attempt tested as silently non-functional against real sustained disk I/O). Happy to answer questions about any part of the implementation, and glad to keep iterating based on review feedback.

Screenshots:

OpenIndiana (VirtualBox VM):

OpenIndiana fastfetch system info (VirtualBox VM):

Solaris 10 x86 (VMWare VM):

T8-1, Solaris 11.4 SPARC, 64 cores (ids 64-127), courtesy of Peter Tribble:

OmniOS (QEMU VM):

[mebenn]

[agorouvein-rgb]

Thanks for trying it out — good to see it working cleanly on your setup too!

[mebenn]

Hey, really nice'; cheers. Compiled directly using gmake. I've got OI running on Linux using VirtualBox .
I've noticed a few niggles though. The CPU info box does not display info on the CPU Hardware. I see you've got the same problem. (Use psrinfo -vp). I'm sure which C++ methods are used by Illumos to retrieve this info and how this uis implemented in btop to do this for Linux. Probably require an #ifdef SunOS or something.
But this is really small stuff that can be fixed later.
If you examine a process by pressing return, the IO/R and IO/W are empty. Have you got the same behaviour?
The number of threads (called LWP on Illumos) seems correct (prstat -p ). I've only checked a few.

I've also tried running it though valgrind; but had to stop as it took for ever. But, in general, btop is very responsive which is good.

Would be nice to test it on bare-metal, i.e, ssh on to a sparc machine. I'll do further testing tomorrow evening and check memory and have a look at the code.

[agorouvein-rgb]

Hey @mebenn

Thanks for the detailed testing, especially catching the IO/R and IO/W issue — that one wasn't actually documented anywhere, so genuinely good find.

Both are fixed and pushed:

CPU hardware name: now pulled from the cpu_info kstat (brand on x86, falling back to implementation on SPARC/wherever brand isn't present), then cleaned up the same way upstream's Linux backend does — strips the boilerplate (Intel(R), Core(TM), CPU @ x.xxGHz, etc.) down to just the model, e.g. i7-6700K. One limitation: I don't have AMD or SPARC hardware to verify against, so while it should work reasonably on those too, the exact cosmetic output (spacing, leftover artifacts on unusual brand-string shapes) is untested there — low risk, but flagging it.

IO/R and IO/W: these were dead code left over from a macOS-derived stub, now implemented via /proc/<pid>/usage. Initially I used pr_inblk/pr_oublk (the seemingly obvious fields), but real testing against sustained raw-device I/O showed they stay at 0 regardless of actual volume — turns out this is a long-documented Solaris/illumos quirk, not specific to this port (Brendan Gregg wrote about it back in 2005, and psutil's own Solaris backend avoids those fields for the same reason). Switched to pr_ioch instead, which does track correctly. The real limitation: pr_ioch is a single combined read+write counter, with no per-direction split available on this platform. IO/R now shows that combined total; IO/W is left blank (not 0 Byte) to signal "not available" rather than falsely claiming zero write activity.

Both tested and confirmed working on OpenIndiana. More broadly (not specific to this latest commit, but worth mentioning for context): the port has also been confirmed on bare metal — an old Acer laptop running current OI — and independently by a mailing-list contributor who compiled and ran it on a T8-1 with 64 SPARC cores.

[mebenn]

Oh, thanks for the fix; fetched merged, compiled and ran and IO/R and W and CPU details correctly displayed

I don't have AMD or SPARC hardware to verify against, ...
but I do, and now my Ryzen 7 3700X with the correct number of cores is correctly displayed. Spacing looks good too.

I've randomly checked the numers on some of the processes against the ptools commands and they would appear to be correct. So things are looking good. Hopefully at the weekend I'll do some deep diving. If there's anything specific you'd like me to check (I'm using OpenIndiana in a VirtualBox on Debian with Ryzen), just let me know.

[mebenn]

Is CMakeLists.txt ok in this PR?

This afternoon I pulled the PR into the openindiana branch but it did not compile: 'SunOS is not supported'.
So I added at line 77: elseif( .... "SunOS")
target.....(... src/sunos/btop_collect.cpp)
(Didn't include the S10 file as I'm not entirely sure whether this effects Solaris 10 ONLY, which I don't have to test)
I also added the NET and kstat (libxnet and libkstat) libs for the link line at lines 252 and 253.

So cmake worked, gmake compillled and is now working and showing infos about my AMD CPUs.

Am I doing something wrong here?

[agorouvein-rgb]

Good catch — you're right, and I see exactly why: this PR only ever updated the Makefile, CMakeLists.txt never got a SunOS branch at all. That message(FATAL_ERROR "${CMAKE_SYSTEM_NAME} is not supported") is what you hit.

Fixed and pushed now — added a SunOS branch in both spots (source selection and platform-link-flags), same pattern as the existing FreeBSD/OpenBSD/NetBSD ones. A couple of notes on how it differs slightly from what you did:

• Linked kstat/socket/nsl rather than your xnet substitution — mainly just to stay consistent with what's already been tested extensively through the Makefile across several machines (OI VM in VirtualBox, OI on Acer Aspire V5-571 laptop, Solaris 10 VM in VMWare, Solaris 11/SPARC on a T8-1 server, OmniOS in a VM). xnet likely works fine too, no reason to think otherwise, just didn't want two different untested-against-each-other lib combinations floating around.
• Deliberately did not copy the unconditional -static-libstdc++ that the OpenBSD/NetBSD branches both have. Oracle Solaris has no static libstdc++ at all — forcing it would break a native build the same way an earlier version of the Makefile did, before that got fixed.
• Left the S10 compat shim out of this entirely, same as you did. Your instinct there was correct — it's genuinely Solaris-10-only, and properly expressing "cross-compile for Solaris 10 from an illumos host" in CMake would need a real toolchain file, which is more than this needed right now.

Built and tested cleanly on OI via cmake -B build && cmake --build build. Thanks for testing your own fix through to a working binary before flagging it — made this a quick, confident fix rather than a guess.

[mebenn]

Good, I'll update to your version: we don't want different versions flying about. I linked in libkstat.so as there is only one implementation for the kstat.h interface.
I used libxnet as it was the first implementation I found that implemented the various missing symbol errors; so I'm happy to go along with your suggestions; but libxnet.so worked well for my tests.
Valgrind exits with an exception, which I was going to use to test memory leeks, so I'll file a bug with the valgrind volks. However, when I originallly tried testing with valgrind, I had to forcibly exit, as it took much too long to run (not unusual for valgrind). So I'll do some memory testing by letting it run for a while and check memory stability (sometime next week though).
S10? I don't have a sun10 image installed anywhere, so I can't test. Coould this be of interest to the Sparc users? Not sure. What I could do would be to add to CMakeLists.txt beneath the if .....(, SunOS) and if ....(, S10); something like
if ...(...,SunOS)
...
if ...(..., S10)
# add the S10.cpp files in ../src/sunos for compilation

In the makefile this is easy to do as we could to a uname -a and parse out the version of Solaris; this is probably possible for CMakeLists.txt; or, if that doesn't work, require a cmake -DS10.
But again, is this a waste of time?

[agorouvein-rgb]

Appreciate you aligning on the libs — agreed, one tested combination is better than two. And no concern at all on the valgrind side; that sounds like the right call (file the upstream bug, let it run properly over time rather than force-killing it). Let us know what the long-run memory check turns up whenever you get to it.

On S10: I don't think it's a waste of time to ask, but I think the uname idea runs into a real problem worth explaining, since it clarifies what S10 support actually is.

Solaris 10 has no C++23-capable compiler at all, so there's no such thing as running cmake/gmake on Solaris 10 to build for Solaris 10 — it's structurally impossible, not just untested. The only way this works is cross-building: you run the build on an illumos host (OpenIndiana, with a modern GCC), producing a binary you then copy over and run on a separate Solaris 10 machine. So a uname check at configure time would always see the illumos build host, never Solaris 10 itself — the target OS and the build OS are two different machines by design, and there's no way to detect "I intend to run this binary somewhere else" from the build host's own uname. That's why the Makefile's S10=true is a manual, explicit flag rather than auto-detected — same thing would need to carry over to CMake as an explicit option(), something like -DBTOP_S10=ON, set deliberately by whoever's doing that cross-build, not inferred.

Separately — worth untangling since your SPARC question conflates two unrelated things: S10 here means Solaris 10 x86, and the shim is x86-specific (a handful of missing libc functions, nothing architecture-level). Peter Tribble's SPARC testing was Solaris 11.4, which has its own modern toolchain and needs no shim at all — so SPARC users are already covered, separately, and get no benefit from S10 support either way. A hypothetical Solaris 10 on SPARC would be a third, completely untested situation — different ABI, and I have no idea whether the current shim's approach would even apply there.

Worth being upfront too: the S10 x86 path itself has only been tested in a VMware VM, not on real hardware — I don't have access to actual Solaris 10 hardware, and as far as I know neither does anyone else who's tested this PR.

Given all that, I don't think it's worth chasing a CMake equivalent right now — not something either of us has the appetite or the hardware to properly verify at the moment. The Makefile path covers it for anyone who needs it.

[mebenn]

I've noticed another flaw: CPU frequency, which should appear on the right of the CPU type. I added this feature and added the code to your branch of openindiana-support. You can get it here:
https://codeberg.org/mebenn/btop.git
(just add this as another repo to your btop working dir, fetch openindiana-support from there and rebase onto you openindiana-support branch.)
If you'd prefer to do everything on Github, just let me know and I'll put it all up to Github. If you have any queries or need anything just let me know.

I'm not sure whether I've implemented everything correctly and I'm unsure whether this will work on all different type of hardware: Sparc???

If you've got other VMs with different systems (Solaris 10/11, SPARC, Intel, ...) it would be very helpful if you were able to run it on each system and activate logging. Then send me the logging.

Here's how to activate logging:
edit: ~/.config/btop/btop.conf
Modify the line beginning with 'LOG_LEVEL' to read:
LOG_LEVEL = "DEBUG"
run btop, then quit and wait until everything is dsplayed
send me ~/.local/state/btop.log
You can rename the log file to refelect hardware/software configuration you are using.

It looks stable oon my machine and I still have to run the long term memory test (thought this missing feature was more important.)

[agorouvein-rgb]

Thanks for this, good catch on the missing frequency. Pulling from Codeberg worked fine, no need to move it to GitHub.

I merged your commit as-is so it keeps your authorship, then added a follow-up commit on top that changes a few things in get_cpuHz():

• Instance lookup: kstat_lookup(kc, "cpu_info", 0, "cpu_info0") assumes CPU 0 exists. That's the same assumption that blanked the CPU panel on Peter's SPARC T8-1, where the ids run 64-127. It now walks the kstat chain for the first cpu_info entry, same as Cpu::collect() and get_cpuName() do. This should answer your "Sparc???" question, though it still needs a real SPARC run to confirm.
• Handle leak: the else { return ""; } branch returned without kstat_close(). Since get_cpuHz() runs on every refresh when "show CPU frequency" is on, any system without that value would leak a kstat handle every 2 seconds. Probably something your long-term memory test would have found eventually.
• Current vs nominal speed: clock_MHz is the fixed rated speed. illumos also has current_clock_Hz, which follows power management, so it now reads that and falls back to clock_MHz where it's missing. It also checks the kstat data type instead of assuming i32.
• Format: it now returns the same style as the Linux backend (2.5 GHz, 779 MHz), which fits the 7-character slot the CPU box reserves. The bare number didn't have a unit.
• Logging: kept your idea of debug logging, condensed to one line per refresh showing which field was used and the value, e.g. get_cpuHz: current_clock_Hz -> 2496 MHz (cpu_info0).

Tested on:

• OpenIndiana VM (KVM): steady 2.5 GHz, as expected, since the guest can't see the host's frequency changes.
• Bare metal OpenIndiana (Acer, i3-3227U): moves between 1.9 GHz and 779 MHz as the CPU idles and loads.
• Solaris 10 1/13 x86 (VMware VM, S10=true build): also has current_clock_Hz, shows 2.5 GHz.

So the clock_MHz fallback hasn't been exercised on a real system yet. SPARC is the most likely place to need it.

A reminder on SPARC, since it keeps coming up: the SPARC support here means Solaris 11 on SPARC, built natively there with its own modern GCC (Peter's T8-1). Solaris 8 and 9 on SPARC won't work at all. They have no C++23-capable compiler, there's no practical way to cross-build for SPARC from an x86 illumos host, and the S10 compat shim is x86-only anyway. Solaris 10 on SPARC is untested and would be a separate project.

On the logging instructions: the setting in btop.conf is lowercase (log_level = "DEBUG"), and btop --debug does the same without editing the config. The log is at ~/.local/state/btop.log as you said, so grep get_cpuHz ~/.local/state/btop.log pulls out just the relevant lines.

Thanks again, and good luck with the memory test.

[mebenn]

I've noticed another flaw: CPU frequency, which should appear on the right of the CPU type. I added this feature and added the code to your branch of openindiana-support. You can get it here:
https://codeberg.org/mebenn/btop.git
(just add this as another repo to your btop working dir, fetch openindiana-support from there and rebase onto you openindiana-support branch.)
If you'd prefer to do everything on Github, just let me know and I'll put it all up to Github. If you have any queries or need anything just let me know.

I'm not sure whether I've implemented everything correctly and I'm unsure whether this will work on all different type of hardware: Sparc???

If you've got other VMs with different systems (Solaris 10/11, SPARC, Intel, ...) it would be very helpful if you were able to run it on each system and activate logging. Then send me the logging.

Here's how to activate logging:
edit: ~/.config/btop/btop.conf
Modify the line beginning with 'LOG_LEVEL' to read:
LOG_LEVEL = "DEBUG"
run btop, then quit and wait until everything is dsplayed
send me ~/.local/state/btop.log
You can rename the log file to refelect hardware/software configuration you are using.

It looks stable oon my machine and I still have to run the long term memory test (thought this missing feature was more important.)

[mebenn]

Ah, thanks. The code, debugging info, etc. were all only temporary, I had expected this commit to be squashed later on. I only know enough about kstat as from the 3KSTAT man page and kstat.h; and I didn't know how to 'aggregate' all CPUs together and take an average? (There is only one display field for it in btop, I think). The only other place to look would be in the Illumos src code.
I had assumed that cpu_info0 would have always been filled (which I was hoping that the logging would have confirmed and then safeguraded with exceptions ).

Have you had access to other sources of kstat.h info? That is interesting (and weird) with the SPARC CPU numeration, or is that a SUN SPARC scheme as opposed to an Illumos SPARC CPU numbering scheme. Wouldn't help if these differed, but if you loop through all cpu_infos, you should be ok.

I had intended to throw nearly all of the get_cpuHz() logging away (as I hadn't a clue about whether i32 was correct over the data field). The logging should maybe be better geared towards new, unknown systems maybe.

[agorouvein-rgb]

Thanks for your contribution. I decided to abandon this project, since I am not a developer and all the code for this pull was written by Claude. According to the updated rules from btop author, this pull will never be merged. You are welcome to continue on your own.