Access to kmem - System namelist - 'ps' etc

Dave Eckhardt dae at psuvax1.UUCP
Thu Dec 27 12:55:30 AEST 1984


[The parent article has expired here.  Oh well...]

I've been thinking on this problem, and have come to what
I think might be a satisfactory answer.

Caveats:
	(1) I am not really a kernel person or a wizard.
	(2) This is still in a rough form.  I hope you can read it.
	(3) I'm lazy and busy.  If anybody wants to write the code...

Well...here goes (~/src/ideas/kernsym/proposal):


How about a

struct usymbol
	{
	char *Sym_name;
	caddr_t Sym_start;
	off_t Sym_extent;
	int Sym_id;
	} usymbols[] =
	{
		{ "symbols", usymbols, 0, 0 }, /* extent filled in later */
		{ "avenrun", avenrun, sizeof(avenrun), 0 },
		{ "proc", proc, sizeof(proc), 0 },
		{ 0, 0, 0, 0 }
	};

in the kernel?  and the following:

struct usymbol getSymbol(name) returns the usymbol entry to the user.
int Symread(symid, offset, buffer, nchars) by analogy to
int read(file, buffer, nchars)

That way the "average" proc could say

struct usymbol procsym;
struct proc p;
int n;
procsym = getSymbol("proc");
for (n = 0; n < NPROC; n++) /* gee, is NPROC a usymbol, too? */
	{
	ngot = Symread(procsym.Sym_id, n * sizeof(p), &p, sizeof(p));
	.
	.
	.
	}
Notes:  the Sym_id field is just the array subscript...I guess
either (a) an initSyms() in the kernel fills them in, or else
(b) the kernel has a modified usymbol structure w/o the Sym_id...

Rationale:

	(1) It makes sense to me that symbols should be named.
	In order to provide for that, there is the getSymbol
	call.  However, since Symread uses a *numerical* id,
	all the kernel needs do is check that
		the Sym_id does exist
		the offset to Symread is >= 0
		offset + nchars <= extent
		copyout the data
	instead of searching the array each time.
	(2) I think an initSyms is a good idea, esp. since
	it is conceptually possible that the size of some
	things is not known at compile-time.
	(3) It's faster than nlist by a good bit, I should think.
	(4) Each site has total control over what symbols are available.
	(5) No reason to take away (k)mem--it's *useful*, just too
	potent for the average user.  (After all, you can use
	kmem to update the usymbols table on the fly, no? :-)


Comments, anybody?  Flames?  Please respond to
...psuvax1!gondor!dae if you think of it.

-- 

 
 \ / \/
  \  / From the furnace of Daemon ( ...{psuvax1,gondor,shire}!dae )
   \/  (814) 237-1901 "I will have no covenants but proximities" [Emerson]

Don't worry--I'm just a piglet of your immigration...



More information about the Comp.unix.wizards mailing list