Chapman Flack wrote:
> 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?

Uh, I thought that some of them at least used ksyms so that they didn't
need an actual kernel binary.  This behavior is IMO better at least in
that this misbehavior that you discuss cannot occur.

Leaving getting this "right" up to the sysadmin seems like a bad
solution.  We have the technology, we can do better.

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

Again, ksyms solves the problem nicely, doesn't it?  At least for most
of these things.  Relying on an on-disk copy of the kernel to help you
find things in *memory* just seems particularly poor.

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191