Comments on: It must be exciting!

By: JÃ¶rg Sonnenbergrer

JÃ¶rg Sonnenbergrer — Thu, 23 Dec 2004 13:26:15 +0000

The plan is indead to make a public interface for the kernel with a helper library to use it. This consists of the important parts.
First of all the kernel ABI must be well-defined and stable. This means that the exported structures have to be independent of the kernel structures, there is no good reason why a change in struct proc forces a recompilation of the userland.
The second part is a consistent userland API. A lot of this code is basically querying a sysctl, but for certain parts, e.g. aggregation of per-CPU done has to be done or dynamic memory has to be allocated. Another important aspect is the possiblity of applying ps or other tools to a coredump. For this, a second library libkcore is provided, with some glue to map the kinfo API to kcore. For a program like ps(1) you just need one additional line to specify the kernel and coredump, change the include from kinfo.h to kcore.h and link to the right libraries. Done.

By: me

me — Wed, 22 Dec 2004 18:12:49 +0000

almost right >)
but there is no need to recompile the libkinfo, it looks as if it is based on sysctls.

By: M M

M M — Wed, 22 Dec 2004 17:41:33 +0000

Looks like they’re making a public interface (libkinfo) of the kernel data structures so that they can change the structs in the kernel without worrying too much about userland binaries.

The old way, you’d have to recompile ps, iostat, top, etc everytime you changed the process structs or the VM structs. Now, it’s probably just a matter of recompiling a single, dynamically-linked library (kinfo).

Any ideas as to what that libkinfo interface would look like though? I imagine it would have to be fairly complex.