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.

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.

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.

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.

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".

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.