On Mon, 11 Nov 1996, Bill Studenmund wrote:

> True, but you always have that problem. My experience (which might not
> match everyone elses, I'll admit) is that I'm often hacking on the kernel
> to do one thing or another. I don't often change the internal structures,
> just where they live.

So long as you don't change the name of the structure, the kmem
library will still find it. (It uses the namelist in the kernel.)
So I'm not sure I understand what you're getting at here, unless
you are talking about booting from a kernel other than /netbsd, in
which case this is currently dealt with by the -N options, and
could be made a bit easier by just symlinking /var/run/kernel to
the booted kernel on boot, and having the kmem lib look at that by
default.

My proposal was indeed to have the information spit out in ASCII
format. (Not that I'm actually all that keen on this proposal; I
just don't see any other way around the problem right now.)

> > If you read strings from multiple files, then you've:
> > 	- made the program that needs the data much slower than
> > 	  it needs to be.

I'm still not sure if I should be taking Jason's coment seriously
or not. Would it really make that much difference? Even on a 3/60?
I find this hard to believe.

> I guess it'd depend on the use for the results. If they are going to go
> to and then back from ascii, you're right that we loose.

Well, yes, we lose some performance. On the other hand, it means
a user can install a NetBSD-1.2B kernel into a NetBSD-1.2 system
and ps(1) will still work.

> I think kernfs/procfs will work better in certain situations, and libkvm &
> friends in others. I think NetBSD will be best served if we balance the
> two possabilities.

Well this is the trick, isn't it. :-)

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.