Simon Burge wrote:
>>From what I understand so far, it's only savecore that really cares
> about the exact location of the kernel?  All the rest of the programs
> can use ksyms or sysctls or whatever instead, and don't need direct
> access to the kernel file itself.

Yes ... they *could* all use sysctls ... the theory is lovely ...
but about 18 of 'em currently don't, and by what date do you predict
all 18 will have been re-engineered to use sysctls?  Bear in mind that
for each one this requires analyzing the data structures it currently
grovels from the kernel, designing an equivalent structure in terms of
sysctl nodes, implementing the kernel code to supply the newly designed
sysctl node interface, and then adapting the userland tool to use it.

In the meantime, any one of these tools, not just savecore, can give
you arbitrary misbehavior if it is wrong about the kernel file to
look in. If the file name it's using corresponds to no file at all,
it will probably give you an error. This is comparatively good. If
the name leads to a kernel but not the exact kernel you specified
at the last boot, they tend to happily and silently give you bogus
information. I mentioned, for example, netstat giving a plausible but
wrong list of currently listening sockets. Think for a moment about
how good this isn't.

The situation where the groveler grovels the wrong kernel is not
unlikely to arise if your kernels live somewhere other than / and
you try the obvious approach of a simple symlink from /netbsd to
one of your kernels.  As long as that's the kernel you boot most
of the time, that'll be right most of the time; the rest of the
time it's wrong. This constitutes a trap for sysadmins.

I think we all agree it would be wonderful to rewrite the grovelers
(or maybe just the 17 that aren't savecore) to use a grovel-free
interface.  In the meantime do we continue shipping the trap
without offering a clearly-documented trivially easy way for admins
to disarm the trap?

The suggestion seems to be to use the continuing pain as motivation
to accelerate re-engineering the grovelers. That would be great if
the pain fell on the people who wrote the grovelers or are in the
best position to rewrite them; but it's more like saying to users/
admins (who have other things to do), here, we know we're shipping
you this problem, we could give you an easy way to deal with it,
but we'd rather leave it aggravating and hope that inspires you to
contribute to our project by rewriting these programs. :P

-Chap