Chapman Flack wrote:
> Garrett D'Amore wrote:
>> There are probably other ideas besides. :-)  The point is, almost
>> anything is better then groveling.  Maybe a dedicated i2c bitbang
>> interface might be worse than groveling.  But not much.
>
> Until this morning I would have said the same thing, but Nathan Williams
> and Matthew Green both got me thinking with their reminders that most of
> these utilities /do need to retain/ their fearsome groveling powers in
> order to be useful on dumps ... and that means if they are using some
> other interface to talk with the running kernel, there comes an eternal
> maintenance issue of ensuring the two interfaces are updated in parallel,
> kept in sync, and the dump functionality doesn't rot. It makes me think
> there's one real advantage to ksyms: you're saved needing to know the
> actual kernel file (which is nuthin' but trouble), but you get to keep
> a lot of your code unforked between the dump and live-kernel cases.
>
> Of course the big advantage of sysctl is the nodes can be active, so
> they can do useful things like lock structures and give you a consistent
> snapshot of something (obviously not an issue with a dump). No doubt
> that's
> necessary in many cases.  But maybe in some cases where something is
> using ksyms and working, the rush to go fix it can be a moderate,
> cautious
> rush.
>
> Just another memo from the Dept. of Vacillation...
>
> -Chap

Having ksyms vs. real files is a big step in the right direction.  But
it doesn't address a few considerations which a proper API would:

    1) A proper API would be exportable to userland applications, and
could easily be retained from update to update

    2) No need to make these tools setid to access all of kernel memory.

    3) A proper API can enforce privilege separation.  For some tools,
like PS, you could imagine a version that doesn't expose processes
outside of a security curtain, etc.

A real API is a lot more flexible, because we can wildly change things
in the kernel and not have to worry about changing user programs, many
of which might not be under our control (think SNMP agents from
companies like CA, etc.)

At some level, this is analogous to why you should use accessor
functions when doing OO design.  Sure, directly accessing state (kernel
memory) is easy, and fast, but it can box you into a corner.

As far as the need to do postmortem analysis goes, I wonder if we might
be better served by having a master kernel debugger with macros that can
perform the functions that are necessary for postmortem.  That debugger
(and the associated macros) could even do *more* things, accessing more
state, without worrying about trying to work on live kernels.  (IMO,
postmortem analysis, or even live debugging of running kernels, is quite
different from the day-to-day tasks of a sysadmin who wants to do 
things like netstat/vmstat/ps just to monitor the health of his system.)

Certainly, it would simplify the code, somewhat, I think, if the
groveling for postmortem were contained within a master debugger.  (One
can imagine something like Solaris' mdb/adb, which has some basic
primitives for accessing the symbol table and memory, and is easily
extensible via scripting.  ddb has some of the same ideas, but lacks
postmortem ability and also lacks any facility for easily adding new
macros.)

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