Supporting running kernel mode unit test in kernel threads

[StevenJiang1110]

Background

The problem arises when attempting to add a kernel mode unit test for CondVar(#675). CondVar is implemented based on WaitQueue and supports similar wait-and-notify families of methods. These methods call the wait-and-wake methods of WaitQueue accordingly. However, the current issue is that kernel mode unit tests are not executed in a thread context, causing panic when the wait method of WaitQueue yields the execution of the current thread.

Brief

Our goal is to run kernel mode unit tests in a kernel thread context, which involves spawning a kernel thread for each test case. This approach offers performance improvements as we can leverage multicore processors by assigning each thread to a separate core. Additionally, it maintains consistency with the behavior of cargo test, where all test cases are run in parallel.

Alternative

Alternatively, we could run all test cases in a single kernel thread instead of spawning a thread for each test case. However, this approach would result in poor performance.

Future Possibilities

If multiple kernel threads are involved, we must consider the scheduler. Initially, kernel mode unit tests can use the default FIFO scheduler. However, we may explore the option of setting different scheduling strategies.

[junyang-zh]

Be sure not to bloat the size of the framework since ktest should be designed as only depending on the framework. The scheduler does not reside in the framework.

We can introduce a new macro API #[async_ktest] and provide a function get_ktest_tasks()->Vec<Task> in the framework and make the user of the framework (aster-nix in our case) responsible for running them.

[tatetian]

Be sure not to bloat the size of the framework since ktest should be designed as only depending on the framework. The scheduler does not reside in the framework.

Which context does the main function labeled by #[aster_main] run in? The task or non-task context? The correct answer should be the former. If not, then it is an implementation limitation that should be fixed. Assuming our answer to the first question is correct, then why can't run the unit tests in the task context?

Yes, the scheduler algorithm can be customized by the user of Asterinas Framework. But it is also true that Asterinas Framework supports running user-given kernel code in multiple tasks (or threads) out of the box.

[grief8]

With #748 , we can support ktests which run kernel mode unit tests in a kernel thread context.

However, the concurrent execution of multiple ktest tasks is still ongoing. I have tried to Incorporate the real execution function fn_catch_unwind into a single task, but libs/ktest relies on the return value of the function. Therefore, this feature will involve a lot of code in libs/ktest. I need your suggestions.

[tatetian]

Be sure not to bloat the size of the framework since ktest should be designed as only depending on the framework. The scheduler does not reside in the framework.

I won't worry about the code bloat of Asterinas Framework caused by adding a default scheduler to it. Here is the reasons.

First of all, a simple FIFO scheduler can be implemented in less 100 LoC, may be 50 LoC. Such a degree of code bloat is acceptable.

Second, this scheduler can be provided under a Cargo feature. This way, the users of the Framework can opt in or out the built-in scheduler depending the situation. For example, aster-nix as a user definitely does not need the scheduler since it will implement much more complicated scheduler, e.g., CFS. But users like ktest or writing-a-new-kernel-in-100-lines example may not have the luxury or willingness to implement a scheduler. So they can rely on the built-in naive scheduler.

[junyang-zh]

libs/ktest is designed to be a standalone crate that does not have any sights on tasks, exception handling, printing, etc. The way is to pass or register functions when using the crate.

This is the original declaration:

pub fn run_ktests<PrintFn, PathsIter>(
    print: &PrintFn,
    catch_unwind: &CatchUnwindImpl,
    test_whitelist: Option<PathsIter>,
    crate_whitelist: Option<&[&str]>,
) -> KtestResult;

A suitable one would be:

pub fn get_ktests<PrintFn, PathsIter>(
    print: &PrintFn,
    catch_unwind: &CatchUnwindImpl,
    test_whitelist: Option<PathsIter>,
    crate_whitelist: Option<&[&str]>,
) -> impl Iterator<Item=impl FnOnce<(), KtestResult>>

You could do it within 100 lines of modification in libs/ktest/runner, not "a lot of code".

[grief8]

libs/ktest is designed to be a standalone crate that does not have any sights on tasks, exception handling, printing, etc. The way is to pass or register functions when using the crate.

This is the original declaration:

pub fn run_ktests<PrintFn, PathsIter>(
    print: &PrintFn,
    catch_unwind: &CatchUnwindImpl,
    test_whitelist: Option<PathsIter>,
    crate_whitelist: Option<&[&str]>,
) -> KtestResult;

A suitable one would be:

pub fn get_ktests<PrintFn, PathsIter>(
    print: &PrintFn,
    catch_unwind: &CatchUnwindImpl,
    test_whitelist: Option<PathsIter>,
    crate_whitelist: Option<&[&str]>,
) -> impl Iterator<Item=impl FnOnce<(), KtestResult>>

You could do it within 100 lines of modification in libs/ktest/runner, not "a lot of code".

Thanks for your advice. I will try to make as small a modification as possible.