Writing portable code that reads /dev/kmem

[Scott Lurndal]

In article <11942:May2521:33:5791 at kramden.acf.nyu.edu>, brnstnd at kramden.acf.nyu.edu (Dan Bernstein)
writes:
|> In article <BLARSEN.91May23060050 at spider.uio.no> Bjorn.Larsen at usit.uio.no writes:
|>   [ wants to put together a kernel-reading program ]
|> > We want to make this program as portable as possible, possibly by
|> > dividing it into one generic part and one system-specific part.
|> 
|> That's always a good idea.
|> 
|> > The UNIX variants that we want to run this daemon on includes SunOS,
|> > Ultrix, OSF/1, SVR4, SVR3.2, Convex UNIX, SCO UNIX, and possibly
|> > others.
|> 
|> My kstuff package runs under SunOS, Ultrix, Convex UNIX, and some
|> others; it should be easy to port to OSF/1, slightly less easy to port
|> to SVR4, and difficult to port to various older System V machines.
|>

I daresay impossible to some SVR4 and SVR3.2 implementations.
 
|> > I've heard rumors that there exists a kmem-access library for BSD4.3.
|> > Would it be feasible to start with this library and port it or
|> > reimplement it on the abovementioned platforms in such a way that the
|> > call interface remains identical on all platforms?
|> 
|> If those rumors are about kstuff, then yes, it should be possible to
|> port while preserving the same interface. kstuff 0.18 was just posted to
|> alt.sources and is available via anonymous ftp to 128.122.128.22 in
|> pub/hier/kstuff:/18.
|> 
|> ---Dan

Since there is no standards requirement for /dev/kmem (and our implementation
of SVR4.0 for the 88100 does not even have one), how portable is any library
that attempts to extract data from an operating system?   To be called unix, 
you must provide certain functionality (defined by the SVID and perhaps
XPG3).  You do not have to internally look anything like unix as provided 
by AT&T (System V) or Berkeley (BSD 4.x); certainly you don't have to use
the same symbol names!

A [more portable] source for perf information on sysV systems would be 
sadc(1) which writes some binary information to stdout concerning
system performance (this is the information used by sar(1) for reports).

Scott Lurndal                 scottl at convergent.com
UNISYS Open Systems Group     uunet!pyramid!ctnews!scottl
San Jose, Ca