DragonFly kernel List (threaded) for 2004-11
Re: iostat, vmstat and other kvm(4) users
:what is the consensus on being able to use e.g. iostat(8) on
:a kernel dump? This is currently possible, because the implementation
:is kvm(4) based and it is therefore free. I'd like to move this and
:other tools in the tree as well (like ps) to the full sysctl-driven
:libkinfo. Beside removing the need for setgid kmem, this also
:consolidates the access to kernel structures. Ideally, the need for
:recompilation this userland tools will completly vanish.
:This does come with a cost and that's the ability to work on core dump.
:I don't think this is a big deal, because this can be done via gdb
:instead, but I don't like to remove functionality without at least
:Another interesting question is the importance of the lastpid field
:top(1) shows. This is based on the nextpid kernel variable and it
:can argued that exposing this e.g. for jails is a minor information
:leak. Do we want to keep this functionality? Should jails show this?
I don't think it's necessary for iostat to work on a kernel dump.
dmesg must work. ps must work. Maybe a few others. But not iostat.