Add NetBSD support in htop(1)

[fraggerfox]

This implementation makes NetBSD use htop(1) without the need of mount_procfs(8).

The implementation has been copied over and modified from the OpenBSD implementation in htop(1).

Make NetBSD no longer masquerade as Linux.

[BenBE]

Thank you very much for your implementation to support NetBSD natively for htop.

As there's one bigger change upcoming that affects all current platforms (and thus also all upcoming ones, I took the liberty to remark on the locations where this potentially requires changes to your PR.

[fraggerfox]

@BenBE Thank you for going through the code and giving a detailed feedback, let me go through each of them and try to resolve it.

[BenBE]

@fraggerfox Another point that came up in discussions in the team was the issue of long-term support of the platform. Would you be willing to help mid-/long-term to keep the NetBSD port up-to-date and aid in debugging issues specific to this platform? Or do you know someone who would be willing to take up on this task?

[fraggerfox]

@fraggerfox Another point that came up in discussions in the team was the issue of long-term support of the platform. Would you be willing to help mid-/long-term to keep the NetBSD port up-to-date and aid in debugging issues specific to this platform? Or do you know someone who would be willing to take up on this task?

Yes, I do not mind putting in my time mid-/long-term to support the NetBSD port. Hopefully, I should have more time to commit to maintenance in the coming months. In case of issues / interruptions I can notify the team ahead of time.

[alarixnia]

In general I think there's lots of interest in this, and I'm also able to help. We're also in #netbsd-code on freenode and can answer questions about APIs and offer testing.

[BenBE]

Changes LGTM.

[BenBE]

Some details still need refinement.

Also may benefit to include ELAPSED column from #627.

Furthermore PROC_EXE (via KERN_PROC_PATHNAME) and CWD (via KERN_PROC_CWD) might be nice to have.

[BenBE]

@fraggerfox Did some commit mashing ;-) No functional changes.

[fraggerfox]

@fraggerfox Did some commit mashing ;-) No functional changes.

Looks good.

[BenBE]

Source-wise it LGTM. Haven't tested to run this though.

[alarixnia]

fraggerfox asked me to test his code, but unfortunately htop fails to configure with NetBSD libcurses.

checking for ncursesw/curses.h... no
checking for ncurses/ncurses.h... no
checking for ncurses/curses.h... no
checking for ncurses.h... no
configure: error: can not find required ncurses header file

this should be unnecessary, as NetBSD libcurses should be good enough.

so, I re-ran configure with export CFLAGS="-I/usr/pkg/include" and export LDFLAGS="-L/usr/pkg/lib -Wl,-R/usr/pkg/lib" so it would find a copy of ncurses I installed.

after this it appears to work fine, although the output is still less useful than top(1) - it groups the file cache together with active memory used by applications, and it does not show kernel threads. it is definitely not a regression from previous htop on netbsd, though

[BenBE]

@fraggerfox asked me to test his code, but unfortunately htop fails to configure with NetBSD libcurses.

checking for ncursesw/curses.h... no
checking for ncurses/ncurses.h... no
checking for ncurses/curses.h... no
checking for ncurses.h... no
configure: error: can not find required ncurses header file

this should be unnecessary, as NetBSD libcurses should be good enough.

so, I re-ran configure with export CFLAGS="-I/usr/pkg/include" and export LDFLAGS="-L/usr/pkg/lib -Wl,-R/usr/pkg/lib" so it would find a copy of ncurses I installed.

Looking through configure.ac we only ever look for the ncurses headers, but not for any headers only called curses.h. Can you have a shot at updating configure.ac to also look for curses.h as a last resort? Also have a look at ProvideCurses.h to see if this needs any updates. That's the only place in htop that directly includes any of the ncurses/curses headers.

after this it appears to work fine, although the output is still less useful than top(1) - it groups the file cache together with active memory used by applications,

This looks like when reading the memory stats some details are still missing. Actually there's a second open point (regarding shared memory) … @Niacat Could you have a look at that?

and it does not show kernel threads. It is definitely not a regression from previous htop on netbsd, though

Can you see if the check for kernel threads in netbsd/NetBSDProcessList.c (here) is done properly?

[fraggerfox]

fraggerfox asked me to test his code, but unfortunately htop fails to configure with NetBSD libcurses.

checking for ncursesw/curses.h... no
checking for ncurses/ncurses.h... no
checking for ncurses/curses.h... no
checking for ncurses.h... no
configure: error: can not find required ncurses header file

this should be unnecessary, as NetBSD libcurses should be good enough.

so, I re-ran configure with export CFLAGS="-I/usr/pkg/include" and export LDFLAGS="-L/usr/pkg/lib -Wl,-R/usr/pkg/lib" so it would find a copy of ncurses I installed.

@Niacat When running the build via the pkgsrc infrastructure these flags are passed in, I guess this is because of USE_NCURSES= yes . When I was building it outside pkgsrc I passed in the flags manually as you have described above.

after this it appears to work fine, although the output is still less useful than top(1) - it groups the file cache together with active memory used by applications, and it does not show kernel threads. it is definitely not a regression from previous htop on netbsd, though

Regarding the memory usage I mostly referred to top(1)'s code and uvm((9)' sysctl interface to get the necessary values.

For the kernel threads, yes I agree, it pretty much does what the current htop(1) does in NetBSD, is there a better way to process this information?

[alarixnia]

We should probably get this merged and improve things further later.

In particular getting it to build with X/Open Curses seems difficult - it is peeking into ncurses-specific structs.

[BenBE]

Could you open issues for the remaining items on your list? What I see is:

• Kernel thread display
• Active / file cache memory display
• X/Open Curses support (NetBSD: Unicode support with X/Open Curses #660)

[fraggerfox]

I opened a couple more tickets for the issues raised.

• Kernel thread display - NetBSD: Counting kernel threads correctly #665
• Active / file cache memory display - NetBSD: Seperate file cache and active memory display #666