DragonFly BSD
DragonFly kernel List (threaded) for 2004-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: iostat, vmstat and other kvm(4) users


From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Sat, 20 Nov 2004 13:21:27 +0100

On Fri, Nov 19, 2004 at 01:26:00PM -0800, Matthew Dillon wrote:
>     I don't mind all normally run programs using the new API, it's just
>     where someone runs 'ps' or 'dmesg' with -N/-M that we need to use the
>     kvm interface.  And, as such, conditional compilation is not the
>     desired solution.  Both features have to be compiled in, but the one
>     that is used would depend on whether -N/-M is specified or not.

I thought about providing a second library (working name: libkcore),
which provides an almost identical API, but adds a init/free function
for a struct kcore and needs this parameter passed to all functions as
first argument. E.g. ps would then have be a single source code using
the kinfo interface with two small conditionally compiled calls to
set a global variable of type struct kcore *. The mapping between the
kinfo and kcore API is done by providing an override kinfo.h with
some macro glue.

libkcore now implements the magic to find the data structures in the
running system or a coredump and convert them to the userland versions.
This makes libkcore directly depending on the kernel ABI and that's
something I want to avoid for ps. One critical part is here that the
normal ps is statically linked and therefore offers to possibility to
change the libkcore implementation. With a dynamically linked ps
(e.g. /usr/libexec/kvm), this problem goes away and we could use the
rpath to check for libkcore in /modules and build it as part of the 
kernel build. That way we have all the necessary infrastructure to
reproduce kernel problems: the coredump, the debug kernel as /kernel
and libkcore.so* in /module.

Joerg



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]