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