Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!mejac!orchard.la.locus.com!fafnir.la.locus.com!richard
From: richard@locus.com (Richard M. Mathews)
Newsgroups: comp.unix.wizards
Subject: Re: Writing portable code that reads /dev/kmem
Keywords: oxymoron
Message-ID: <1991May29.194800.1803512@locus.com>
Date: 29 May 91 19:48:00 GMT
References: <BLARSEN.91May23060050@spider.uio.no> <76560@brunix.UUCP>
Organization: Locus Computing Corporation, Los Angeles, California
Lines: 19

cgy@cs.brown.edu (Curtis Yarvin) writes:
>Your best bet is to make a very explicit split between the portable and
>nonportable modules of the monitor daemon.

I might even go farther than that.  I'd have a completely portable frontend
which only understands high level concepts like "get me the performance
data."  For many systems, there will be a large amount of common code in
the non-portable backend; so I'd split it into 2 parts -- a semi-portable
piece which works with most systems and a completely system-dependent
piece which deals with each system's idiosyncrasies (such as the names
of the kernel variables).  For a few systems, such as those which don't
let you directly read kmem at all, both of these pieces would be replaced
by a system-dependent module.  On the majority of systems, however, the
semi-portable piece would be usable.

Richard M. Mathews			Lietuva laisva = Free Lithuania
richard@locus.com			Brivu Latviju  = Free Latvia
lcc!richard@seas.ucla.edu		Eesti vabaks   = Free Estonia
...!{uunet|ucla-se|turnkey}!lcc!richard