Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!voder!pyramid!ctnews!risky!pase70!scottl
From: scott@convergent.com (Scott Lurndal)
Newsgroups: comp.unix.internals
Subject: Re: Interfaces for accessing kernel memory
Message-ID: <2090@risky.Convergent.COM>
Date: 13 Dec 90 21:55:27 GMT
References: <109449@convex.convex.com> <axhux8.50q@wang.com>
Sender: root@risky.Convergent.COM
Reply-To: scott@convergent.com (Scott Lurndal)
Organization: UNISYS Computer Systems Product Group, San Jose Ca.
Lines: 51

In article <axhux8.50q@wang.com>, mike@wang.com (Mike Sullivan) writes:
|> tchrist@convex.com (Tom Christiansen) writes:
|> 
|> >We've all written (or at least seen) programs that make kernel dives
|> >into /dev/mem using an nlist from /vmunix in order to figure out what
|> >some particular kernel variable looks like, or perhaps even to change
|> >it.
|> ...
|> 
|> >arrays of structures?  Wouldn't it be nice to be able to get the first,
|> >then the next element until null, of the array?
|> 
|> >--tom
|> 
|> When I worked at Alliant our arrangement was very simple, we mapped the
|> kernel memory into the process (typically read only ;-) which needed
|> access.  Since my only interest was in the proc table, and a few other
|> structures which didn't have much call to change, it was immune to 
|> OS changes.  The direct mapping of kernel memory made linked lists very
|> easy to follow.
|> 

Wait a minute, there is nothing that states an implementation of unix 
is required to have a proc table (and I know of at least one which doesn't).
Nor is a proc table immune to os changes.   Exporting knowledge of 
operating system data structures is a sure way of restricting the
ability of operating system designers to change the internals of
an operating system - which no self-respecting application should know.

Your alliant applications would most likely only run on alliant 
systems - even then I suspect that the alliant o.s. engineers would
not restrain themselves from changing the format of the proc structure
just so that programs that know it will still run and/or compile.

The solution is to export interface-defined structures, independent of
the internal format (like the PIOCPRSTATUS and PIOCPSINFO requests in 
system V 4.0 /proc file system).   This allows for portable applications
which are not dependent on a particular version of a particular o.s.
In fact, such an interface could be defined so that new
information could be provided (with new releases of o.s.) in such a 
way as to not break existing programs (e.g. $GETJPI in VMS)

|> -- 
|>   ________________________
|>  /                    __  \  | Michael J. Sullivan    | "Used to be different,
|> | \  \  /  /\  |\ |  /  `  | | Wang Laboratories Inc. | Now you're the same,
|> |  \/ \/  /--\ | \|  \__T  | | mike@WANG.COM	      | Yawn as your plane"
|>  \________________________/  | 			      |	goes down in flames"

Scott Lurndal
scottl@convergent.com  {uunet|sun}!pyramid!ctnews!pase70!scottl