On 20/05/15 04:00, Ryota Ozaki wrote:
I have a feature request to rump_server.
I want to output kernel logs of a rump_server into a file.
I know we can get kernel logs with rump_server -s -v,
but it doesn't satisfy my requirement; I sometimes want
to get kernel logs from a detached rump_server,
for example, when I debug a kernel using ATF tests.
Using gdb is another way to get kernel logs (suggested
by pooka), but it is difficult to cooperate with ATF
tests.
As it happens, last night I needed to get the dmesg from a rump kernel
running on bare metal, so I made a trivial adjustment to make the
kern.msgbuf sysctl node available. Now you can get the log slightly
more easily than with gdb by using sysctl -r kern.msgbuf (I assume
hijacking dmesg(1) would also work on NetBSD).
However, fetching dmesg via sysctl still requires a running (i.e.
non-crashed) rump kernel, which may be suboptimal for ATF tests in case
you e.g. want to perform fault injection to break an invariant and make
sure that the kernel detects it and panics the right way instead of
corrupting state.
I imagine something like rump_server -L <file> option
for specifying an output file. In an ATF test, we launch
a rump_server with the option and at the cleanup phase
of ATF, we get kernel logs from the file by simply
catting the file or somehow.
How about the feature? If there is another way to do
what I want to do, please let me know.
Can you sketch a bit how you'd integrate the feature with ATF? For
example, do you plan to always include the log of all rump kernels
started by ATF in the test output (how?) and leave parsing to a human
reading the logs, or will the logcat be executed only by a failure
handler, or something different?
I think -L is fine, but I'd like to see at least one concrete example --
and preferably more than one -- on how you plan to use the feature to
make sure -L is really the best possible way instead of just fine.
- antti
