KTEST_CREATE_MODULE(9F) | Kernel Functions for Drivers | KTEST_CREATE_MODULE(9F) |
ktest_create_module
,
ktest_add_suite
,
ktest_add_test
,
ktest_register_module
,
ktest_unregister_module
,
ktest_free_module
— create
and register ktest test modules
#include
<sys/ktest.h>
int
ktest_create_module
(const char
*name, ktest_module_hdl_t **km_hdl);
int
ktest_add_suite
(ktest_module_hdl_t
*km_hdl, const char *name,
ktest_suite_hdl_t **ks_hdl);
int
ktest_add_test
(ktest_suite_hdl_t
*ks_hdl, const char *name,
ktest_fn_t fn, ktest_test_flags_t
flags);
int
ktest_register_module
(ktest_module_hdl_t
*km_hdl);
void
ktest_unregister_module
(const char
*name);
void
ktest_free_module
(ktest_module_hdl_t
*km_hdl);
Volatile - This interface is still evolving in illumos. API and ABI stability is not guaranteed.
A ktest test module is created by building up a module object and registering it with the ktest facility. The module object consists of a name and one or more suite objects. The suite object consists of a name and one or more test objects. Each test object consists of a name, a function pointer to the test function, and a set of test flags.
Test module object creation and registration should happen as part of the test module's _init(9E) routine. The sequence of calls inside a test module's _init(9E) should proceed in the following order.
ktest_create_module
()ktest_add_suite
()ktest_add_test
(),
1 or more timesktest_register_module
()Conversely, the test module should unregister its test module object as part of its _fini(9E) routine.
The name is the string used to reference a particular module, suite, or test. Any given test is uniquely identified by the combination of its module, suite, and test name -- also referred to as its "triple". This triple is how the user identifies a test when making use of the ktest(8) command.
The module name may be the same as the module-under-test, but that isn't a requirement. At the end of the day, the test module's name is simply a string used to organize suites of tests in some logical manner. In some cases it makes sense to name the test module something other than the module-under-test. For example, when the module-under-test is large, such as genunix. Or when the test module is testing a property of the larger system that spans more than a single module.
Module names must be unique. Suite names must be unique for a given module. Test names must be unique for a given suite. That implies that suite and test names may be reused so long as they are unique within their given namespace.
The ktest_create_module
(),
ktest_add_suite
(),
ktest_add_test
(), and
ktest_register_module
() functions return 0 on
success or an error value for failure.
The following example provides a template for how one would typically organize the source code of a test module.
#include <sys/ktest.h> void foo_test1(ktest_ctx_hdl_t *ctx) { ... } void foo_test2(ktest_ctx_hdl_t *ctx) { ... } void foo_test3(ktest_ctx_hdl_t *ctx) { ... } static struct modlmisc foo_test_modlmisc = { .misc_modops = &mod_miscops, .misc_linkinfo = "foo ktest module" }; static struct modlinkage foo_test_modlinkage = { .ml_rev = MODREV_1, .ml_linkage = { &foo_test_modlmisc, NULL } }; int _init() { int ret; ktest_module_hdl_t *km = NULL; ktest_suite_hdl_t *ks = NULL; VERIFY0(ktest_create_module("foo", &km)); VERIFY0(ktest_add_suite("suite1", &ks)); VERIFY0(ktest_add_test(ks, "foo_test1", foo_test1, KTEST_FLAG_NONE)); VERIFY0(ktest_add_test(ks, "foo_test2", foo_test2, KTEST_FLAG_NONE)); VERIFY0(ktest_add_test(ks, "foo_test3", foo_test3, KTEST_FLAG_INPUT)); if ((ret = ktest_register_module(km)) != 0) { ktest_free_module(km); return (ret); } if ((ret = mod_install(&foo_test_modlinkage)) != 0) { ktest_unregister_module("foo"); return (ret); } return (0); } int _fini(void) { ktest_unregister_module("foo"); return (mod_remove(&mac_test_modlinkage)); }
February 8, 2024 | OmniOS |