/dev/drum versus libkvm?
hmp at backplane.com
Sun Apr 10 15:48:50 PDT 2005
I notice that libkvm uses some values defined in <sys/paths.h>
but one of those paths doesn't exist in DragonFly:
#define __SYS_PATH_DRUM "/dev/drum"
<sigh> The joke's on me again. After reading thru the sourcecode
for libkvm I see that the kvm_open() function completely *ignores* its
third argument, and that's the argument that would have used /dev/drum.
So it doesn't matter after all.
I'd still like to know what is going to replace libkvm when it goes
away, as Hiten predicts. Would it be libkinfo?
Not predicting, know for a fact. :-)
Gather around children, as I have a tale to tell... some time ago,
Joerg and I discussed that the current libkvm use is actually nor
clean enough nor helping it make easier for writing programs that
use information from things like struct proc, etc -- they end up
becoming out-of-sync with an updated/different kernel thus giving
us all sorts of problems.
Secondly, we wanted to make use of sysctls for retrieving the
information instead of making libkvm calls. Such sysctl calls
are currently used in a redundant manner. For this, we wanted
to introduce two APIs, one for accessing normal kernel data,
while the other can be used for hard kernel core information
That was the basic consensus if I recall correctly. The APIs are
not complete at the moment nor have we done a runner for converting
them just yet because some things still need to be worked out.
More information about the Bugs