Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Jul 2014 18:20:40 -0700
From:      Garrett Cooper <yaneurabeya@gmail.com>
To:        Julio Merino <jmmv@freebsd.org>
Cc:        "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org>
Subject:   Re: Location of test kernel drivers in tree?
Message-ID:  <CAGHfRMCWJXi82AQA_vgWUkjWGXc86subB_0u18R9MgAnXfo_pQ@mail.gmail.com>
In-Reply-To: <CAFY7cWCR_bUjm4KSLow85%2BeshTgDVzPCF5iJVS0rb37Lh7zGWQ@mail.gmail.com>
References:  <CAGHfRMC==6WRKwd13R7Yyjyu%2B_Oi_173TLTXPVk9ynH0G5qqxg@mail.gmail.com> <CAFY7cWCR_bUjm4KSLow85%2BeshTgDVzPCF5iJVS0rb37Lh7zGWQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 23, 2014 at 6:11 PM, Julio Merino <jmmv@freebsd.org> wrote:
> On Tue, Jul 22, 2014 at 7:07 PM, Garrett Cooper <yaneurabeya@gmail.com> wrote:
>> Hi all,
>>     I need to do some KPI verification and hook that into ATF / kyua.
>> Since we don't have RUMP [yet] from NetBSD, I would typically write a
>> simple, one-off test driver, hook it into the kernel build and have a
>> piece of C or shell code that pokes directly at the driver to get
>> access to kernel interfaces.
>>     I was wondering if it made sense to put all test drivers into
>> sys/tests/<module-name>/..., e.g.
>> sys/tests/test_memguard/{Makefile,test_memguard.c}, etc. Is there an
>> alternative approach that others use to solve this problem?
>
> I don't have an answer to alternative solutions, but keeping the
> helper modules inside tests/sys/ (I think you got that backwards in
> your email?) is a good idea.

I was thinking of sys/tests (with associated build machinery under
sys/modules/tests) because the kernel and world [*] build vary wildly
by design.

> (Instead of tests/sys/<module-name>/, I'd probably do
> tests/sys/<thing-being-tested>/<module-name>/... though, to keep the
> helpers next to the only tests that need them. Unless the helper is
> really generic and usable by many tests.)

Most definitely!

Thanks :)!!
-Garrett

* There's MODULES_WITH_WORLD [see make.conf(5)], which is off by
default, so technically modules can be built with world, but I'm not
sure how well it works when you have to have to use opt_* headers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGHfRMCWJXi82AQA_vgWUkjWGXc86subB_0u18R9MgAnXfo_pQ>