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

看板DFBSD_kernel作者時間21年前 (2004/11/20 20:32), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串7/7 (看更多)
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
文章代碼(AID): #11dpb800 (DFBSD_kernel)
討論串 (同標題文章)
文章代碼(AID): #11dpb800 (DFBSD_kernel)