Date: Fri, 24 Jun 2011 08:55:07 -0700 From: mdf@FreeBSD.org To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, Sebastian Huber <sebastian.huber@embedded-brains.de> Subject: Re: Unit Tests for FreeBSD Kernel APIs? Message-ID: <BANLkTi=kF-SpoiLt5d26PqNWU0L1QzZq5A@mail.gmail.com> In-Reply-To: <201106240914.49279.jhb@freebsd.org> References: <4E043B5F.3080908@embedded-brains.de> <201106240914.49279.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 24, 2011 at 6:14 AM, John Baldwin <jhb@freebsd.org> wrote: > On Friday, June 24, 2011 3:23:11 am Sebastian Huber wrote: >> Hello, >> >> exists there some unit tests for FreeBSD kernel APIs, e.g. mutex(9), >> condvar(9), etc.? >> >> Have a nice day! > > Hmm, I have a kernel module that does some tests, but it is not in the tr= ee. > One of the issues is that many of the tests you want to do for some of th= ese > APIs involve timing. =A0For rwlocks, for example, I used KTR traces and u= sed > a kernel module that forked 4 threads to all compete over a single lock. = =A0I > then verified via KTR traces that every branch was taken (and made libera= l > use of KASSERT()s which caught a few edge cases I had missed initially). At $WORK we have a generic TEST_THREAD interface which allows for calling essentially random kernel code (whatever a dev codes up) with arguments. At the shell one types "test_thread foobar(12345, \"string\")" or whatever args. The test_thread syscall looks in the set of registered functions for foobar, and passes off a string with (12345, \"string\") to the function. Each function is responsible for parsing its own arguments. The args for the test_thread function pointer are the $WORK equivalent of and input sbuf and and output sbuf, which is copyout'd to the calling binary. If there's interest I can clean up the patch a little to show proof-of-concept that builds without all the $WORK gorp. We use this for a few things: unit-testing kernel code, hand-editing of filesystem data to recover customer sites from kernel bugs (sometimes this is possible), etc. Cheers, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=kF-SpoiLt5d26PqNWU0L1QzZq5A>