On Mon, 11 Nov 1996 12:49:34 -0800 (PST) 
 Curt Sampson <cjs@portal.ca> wrote:

 > > > 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.

Yes, I'm totally serious... Let's assume that we're looking at, say,
the process list.  Let's say there are many processes running (something
larger than 200, perhaps).  Doing a "ps" using strings, and converting
those strings to the appropriate numerical value is going to be
expensive in terms of cpu time, and as such, further opens up the window
of opportunity for race conditions.

Plus, where do you put that code?  In ps(1), vmstat(1), iostat(1),
netstat(1), etc?  It's not clear that you can put this code into
a library, since the interpretation of the strings may be handled
very differently from program to program.

Also, say a value in the kernel was changed from a short to an int.
Let's say the program that reads this value assumes it's a short,
and converts to a short when reading the string.  Now, let's say
that the program reads this value string, but the string represents
a number that's larger than a short.  You lose.  Now you have to
update the program that reads this value.  This is now a hard problem,
since you actually have to change the programs, not to mention _find_
all of the programs that read the value.  The _only_ way to maintain
any sort of consistency is to use kmem and structures.

As I've already stated, we can't get rid of the kmem interface to these
programs, since we need them in order to read kernel crash dumps.

That's a lot of additional code complexity.

 > 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.

Well, my opinion on this is that if you're going to install a
-current kernel and/or track -current, then you ought to be willing
to reinstall the programs that grovel through kmem.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939