Very Computer

I am trying to create a really trimed system load average utility
which only reports average number of job in the run queue over the
last 1 minute, I prefer not to use top(1) and uptime(1) since both
have other mechanisms for features that I don't need.

A quick hack got the binary working (I admit that I "borrowed" some
codes from top/machine/m-sunos5.c :).  However, upon reviewing the man
page for kvm_read, I noticed that in the USAGE section, the following
statements:

USAGE
     The  use  of  kvm_read()   and   kvm_write()   is   strongly
     discouraged.  On some platforms, there is considerable ambi-
     guity over which address space is to be  accessed  by  these
     functions,  possibly  leading  to  unexpected  results.  The
     kvm_kread(),  kvm_kwrite(),  kvm_uread(),  and  kvm_uwrite()
     functions are much more clearly defined in this respect.

[....]

SunOS 5.7           Last change: 22 Sep 1997

However, the API for both kvm_kread and kvm_read are the same:

SYNOPSIS
     #include <kvm.h>

     ssize_t  kvm_read(kvm_t  *kd,  uintptr_t  addr,  void  *buf,
     size_t nbytes);

     [...]

     ssize_t kvm_kread(kvm_t  *kd,  uintptr_t  addr,  void  *buf,
     size_t nbytes);

Since both need the kd pointer, so why the man page claims so is
puzzling to me?  Even calling kvm_kread, I have to provide the kd
pointer anyways.  To get that, I suppose I need to call kvm_open too.
In any case, I would appreciate any enlightening in this regard, or a
few pointers to the right documentation set.  I am very willing to dig
further.

Regards,

Chin Fang

The man page is alluding to the fact that kvm_read historically interpreted
virtual addresses below KERNELBASE as requests to read from the address
space of the current user process (as defined by kvm_setproc/kvm_nextproc)
instead of the kernel's address space.  Meanwhile, if your goal is to write
a load-average printer, look into getloadavg(3C) instead of libkvm.  This
has the advantages that: (1) you write less code, (2) you don't need to
be 64-bit to examine a 64-bit kernel, and (3) you don't break when the
kernel changes in the future.

-Mike

--
Mike Shapiro, Solaris Kernel Development.