iostat, vmstat and other kvm(4) users

[Matthew Dillon]

: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 at xxxxxxxxxxxxx>