It seems to me that a whole bunch of effort is being expended in attempting
to work out how to better support a truly brain dead interface ...

Grovelling about in /dev/[k]mem for your average application level
program just can't be the right way - its insane.

Way back in 6th edition days someone (I can't remember who, apologies to
whoever did this) created a "table driver" which essentially removed all
of that grovelling from all the applications that matter.   The driver
amounted to a (compiled in) array of structs, indexed by minor(dev) with each
struct giving the kernel base addr & size of some kernel table which was
of interest to user level applications.   Adding support for a new table
meant adding a new entry to that array.   The rest of the driver was just the
read routine, which was basically just a bounds check and copyout().

These days, we wouldn't use a driver for this purpose, more likely a
filesystem type (probably kernfs) but the precise interface doesn't matter.
Further, we'd probably complicate the internals a little to allow for a
simple linear interface to kernel structs that are no longer simple linear
entities (internally malloc'd lists, etc).   None of that is important,
what is, is that the kernel ought be exporting the data that the applications
require - certainly not the dev/[k]mem offsets to allow the application to
climb into the mud.

That way it is possible to take care of essentially everything, and what's
more, also allow more fine grained access control than is possible with
everything just playing in the /dev/[k]mem mud pit.   For the few applications
where this makes no sense at all (like gdb of a crash dump) things just stay
as they are now.  I think it just conveniently turns out that none of those
really give rise to the problem which started all of this - that is, fairly
important stuff which simply "knows" that /netbsd is the place to go to get
the offsets into /dev/[k]mem.

Finally, yes, I know that making a change like that this breaks the ability of
things like the -M arg to ps (the ability to do a ps of a crash dump).
Frankly, I don't care, and I doubt most users do either.   But if that's
considered important, the very few applications where it is actually useful
can keep the nlist & grovel mechanism for use when the relevant args are
given (which will never be from anything which does not simply know which
is the right symbol table - or should ... ie: this comes from humans).

Oh, and one last issue - I have no more sympathy for people who say "but I
don't want to run kernfs" than for people who say "I don't want a /etc".
At some point things simply need to be considered to be a fundamental part
of the system, and not optional.

kre