On Wed, May 20, 2015 at 8:44 PM, Antti Kantee <[email protected]> wrote: > 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).
rump.sysctl -r kern.msgbuf works (though some NULL bytes appears before actual kernel logs), however, dmesg with hijacking doesn't. dmesg still shows host's kernel logs. > > 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. Yes. The above feature is useful but not enough. > >> 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 thought I use kernel logs for debugging a kernel with ATF tests. So I wouldn't output kernel logs by default in ATF (it may be useful though). I imagined the following scenario: - Modify the code of the kernel and test it with ATF tests - Find a regression via an ATF test - Want to debug the kernel with the ATF test - Try printf debugging of the kernel (add printf to the code) - Let rump_server(s) dump kernel logs at the cleanup phase (or somewhere) (it may be done by just enabling a debug flag of the test if it supports or adding some code to the test if not.) - Run the ATF test again, see the output and debug it If printf debugging is not sufficient, move to use of gdb, though I have no idea on using gdb with ATF tests easily. Support of kernel log output in ATF would be like this: http://www.netbsd.org/~ozaki-r/atf-dmesg.diff > > 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. Well, another example would be to use kernel logs in test itself, e.g., atf_check -s exit:0 -o match:'something' dmesg. I'm not sure such tests are proper. ozaki-r
