Subject: Re: word processor that runs on NetBSD/i386? (FAQ?)
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Stefan Grefen <grefen@hprc.tandem.com>
List: port-i386
Date: 07/01/1998 09:58:26
In message <199806230318.UAA03835@lestat.nas.nasa.gov>  Jason Thorpe wrote:
> On Mon, 22 Jun 1998 22:55:15 -0400 (EDT) 
>  woods@most.weird.com (Greg A. Woods) wrote:
> 

[...]

> So... this seems to come up often enough that it should be a FAQ,
> but here it goes:
> 
> 	1.  You have to keep the kmem parts of the programs around so you
> 	    can debug crash dumps.  This is irrelevant for Linux, since they
> 	    don't even HAVE crash dumps.

I think this is the important reason. For a decent system there must be ways
to do post-mortem analysis ...

> 
> 	2.  If the data from the /proc/... files is binary, you still have
> 	    structure version skew problem that kmem has.
> 
> 	3.  If the data is string format, you have the problem that you're
> 	    forcing the data to be represented in a certain way, and
> 	    you can't easily change it.  (If you want to represent differently,
> 	    then you have to parse strings, which is slow and has the same
> 	    version skew problem that binary data does!)

Those two point I don't buy. There are various methods to encode this binary
in way the application can figure out the data-length, value ranges and
meaning of a parameter. It won't be much slower than reading the symbol-table
and rumbling through /dev/kmem.
(ASN.1, RPC marshalling ...) :-)) 
Oops, now I see multiple heavy object flying in my direction ... :-))


And there are reasons (security) to disallow acces to /dev/?mem even for root 
or group kmem, but I don't think it's worth the effort for the average
NetBSD usage.

Stefan

> 
> Jason R. Thorpe                                       thorpej@nas.nasa.gov
> NASA Ames Research Center                            Home: +1 408 866 1912
> NAS: M/S 258-5                                       Work: +1 650 604 0935
> Moffett Field, CA 94035                             Pager: +1 650 428 6939

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---