Re: iostat, vmstat and other kvm(4) users
:Hi all,
: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
:a warning.
:
: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?
:
:Joerg
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.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 2 之 7 篇)：