Hi,
many moons ago, I mentioned the system monitor I wrote in some thread
here on misc@, as it was possibly useful for someone then. I continued
working on it, and it has come a long way since. Initially written on
and for OpenBSD, it now also runs on FreeBSD, NetBSD, Linux, Solaris,
and a bit of Mac OSX, too, and also has a whole bunch of new features.
Here is XMLSysInfo (aka XSI), including lots of additional information
on it: http://xsi.kolabore.ath.cx/ (There's also an OpenBSD port there.)
I am now at the point where I would change its "alpha" status to "beta".
However, that would also mean "no new features" and "only important bug
fixes for the XML Schema allowed". Because of this, I am making this
request for comments and feedback. If you're interested in a system
monitor like XSI, please check it out and let me know if there's some
feature that you'd need, and whether you can find inconsistencies or
something that seems illogical in the output or the schema.
Your help (and, of course, any other kind of feedback as well) is very,
very much appreciated. Please be so kind to not bother this mailing list
with replies to the off-topic parts of the mail.
Now ...
So I wrote a system monitor, and ported it to a bunch of operating
systems. This means, I got to learn and deal with a lot of
kernel<->userland APIs.
Almost every OS had few or more parts that were fun to implement. In
that regard, OpenBSD clearly stands out as the pure-fun operating
system, with no "nasty surprises" whatsoever. After years of using
OpenBSD, I became spoiled of how everything Just Works, and started to
take all the goodness for granted. My recent programming, however,
reminded me of why I actually like OpenBSD -- the consistency, excellent
documentation, and ease-of-use is everywhere[1], including API-land.
There was no half-baked crap to be found, and what I wrote was
immediately architecture-independent. Thanks for the joyride!
[1]: For various meanings of "everywhere". As in "most" and "all
important" areas. A year ago, I stumbled a bit through PPP-related code
in both kernel- and userland ... that was irritating.
Or, in retrospect, looking at my OpenBSD-specific code, it's boring:
sysctl(3) in most places, no kludges ... all the interesting information
is readily available. Luckily, it was the first thing I wrote, so it was
still very interesting at the time. :-)
About the others ... well, here's the list of ports I wrote, ordered by
my personal sanity level, from high to (very) low, while writing them
(might apply to API quality as well ;-)):
OpenBSD
FreeBSD (*)
Solaris
NetBSD (*)
Linux
(*) means that I was surprised by the result.
Enough praise for OpenBSD ... there's nits to pick! Boohoo, I need to
try and look at an arbitary number of sysctls to get all sensors (I went
with 256 like sensorsd(8).) On the other hand, I'm pretty sure that
doing it like this simplyfies a lot of other code, so all is well.
Still, a HW_SENSORS_NUM sysctl would be nice to get the number of
sensors that I should try to read. That, and ... hm, nothing. The code
to get the default routes looks scary, but that's scary everywhere all
the same.
FreeBSD surprised me a bit, as I expected it to be quite different.
Turns out it actually is different, but most things (at least those it
actually supports) were pretty easy to do. Only mild inconsistencies wrt
reading the CPU frequency, and, like on OpenBSD, I can get all that
stuff while being confined in a chroot with minimal privileges.
Solaris doesn't have sysctl(3), but a comprehensive sysinfo() that
helps. The ioctl(2) stuff about networking stats is crazy and
complicated. Fortunately, talking to the kernel directly isn't needed in
most other cases, as there are some libraries for this kind of stuff
that have well thought-out and properly documented APIs. On the other
hand, what these libraries actually return seems to be neither
standardized nor documented anywhere. There's some guesstimating going
on, so I'll have to see how that port fares over time ... On Solaris, it
is impossible to be chroot()'ed as a system monitor like XSI. Oh, and
heed the warning about "evolving" APIs. They like to make really
pointless changes to them between releases.
NetBSD was rather disappointing, from my point of view. Thanks to the
common heritage with OpenBSD, some copy+paste was possible. Where they
diverged over the years, things get "interesting". Being able to get the
CPU frequency depends both on the architecture and whether one or
another LKM is loaded. Then, there's that weird "security feature" that
the kernel seems to actively hide insensitive information about
filesystems mounted outside the chroot. That's nonsense, and means that
I can't chroot() here, either. Enter the big, non-backwards compatible
API changes between releases wrt disk I/O. This shall be forgiven,
however, since the old structure and sysctl names would have made other
I/O-related extensions illogical. And: AOUUGH! The interrupt stats are
/so/ difficult to get. That is, it'd be easy with kvm(3), but being sgid
kmem is a risk I wouldn't take. I tried to get interrupt names and
counters from ksyms(4), but that was just too hard for me (help/patches
welcome!). In the end, I opted for execl("vmstat", "-i"), and I'm not
proud of it.
Now ... dare I talk about Linux, for completeness sake? I shall not, at
least not as verbosely. I'm still getting angry just thinking about it.
No /usable/ sysctl(), not only inconsistent proc file formats but also
architecture-dependent contents ("cpu MHz" vs "cycle frequency [Hz]" vs
"clock"), a truly horrible sensors "API" where one can easily get lost
in sysfs' circular symlinks, the need to be root to get information
about network interface media, a disgusting API called "Netlink" that is
incredibly hard to use and that just asks for fragile code, and ...
*take breath* ... more. It's as if Linux kernel developers don't talk to
each other. Not to forget, the true Necronomicon is right there, in
linux/Documentation/.
Alright now, that's it, I'm done with the relatively off-topic essay, I
hope it was somewhat informative (maybe even entertaining? :P) and
didn't ruffle too many feathers for being so long and not entirely about
OpenBSD. And, please remember to give me some feedback on XMLSysInfo!
Thanks, and have a good weekend,
Moritz
