More and more kernel test cases will be integrated to oeqa recently. Based on my experience, Most kernel features dependend on certain kernel configs while some of those configs are not enabled by default configration. we need a place to record this kind of depenency for each test case or a mechnism to satisfy the kernel configs requirement in the build process ie: a)test case A require CONFIG_XXXX, we should make sure CONFIG_XXX is enabled when test A is in "TEST_SUITES" (known as test plan) b)or we need to document this to record this dependency at least if we can't implement a) and test case need to check if those requirement gets satisfied at the begining. or it will exit at early time and give error info. Lei
It would be great if the test could check /proc/config.gz (if it exists, but maybe this could be a minimum requirement for testing) and if any required configs are missing the test should be recorded as SKIPPED and the missing config recorded in the log file.
Is this covered already by your patch: [OE-core] [meta][PATCH 0/2] Add kernel-sample tests for runtime test
(In reply to comment #1) > It would be great if the test could check /proc/config.gz (if it exists, but > maybe this could be a minimum requirement for testing) and if any required > configs are missing the test should be recorded as SKIPPED and the missing > config recorded in the log file. Yes, I have checked the necessary config or .ko in the patch. Maybe it should be perfected.
(In reply to comment #2) > Is this covered already by your patch: > [OE-core] [meta][PATCH 0/2] Add kernel-sample tests for runtime test No, OE-core hasn't merge the patch into master.
(In reply to comment #3) > (In reply to comment #1) > > It would be great if the test could check /proc/config.gz (if it exists, but > > maybe this could be a minimum requirement for testing) and if any required > > configs are missing the test should be recorded as SKIPPED and the missing > > config recorded in the log file. > > Yes, I have checked the necessary config or .ko in the patch. > Maybe it should be perfected. (In reply to comment #2) > Is this covered already by your patch: > [OE-core] [meta][PATCH 0/2] Add kernel-sample tests for runtime test no, this pacth doesn't cover this, it's far more away from the goal I expected. 1) Our final goal is to know which test depend on which kernel cfg easily. 2) how could easily enable those kernel configs by the build system. like when testA is in your test plan, its required kernel configs need to be enabled by build system automatcially
Please be aware that, this is high level request. The background I proposed this is : most kernel tests would depends on certain kernel different configs. Imageing we have 100 test suite for kernel, how could you know which kernel config is for which test suite, for examples, you add 50 kernel test suites in the "TEST_SUITES", you end up finding that most of the kernel configs are not enabled you got 49 failure. so we'd better to eanble the test configs automatically, for example, test_A required CONFIG_XXX, CONFIG_XXX sould be automatically enabled if (only if) test_A is in your test plan (TEST_SUITES) . Lei
(In reply to comment #6) > Please be aware that, this is high level request. > > The background I proposed this is : > > most kernel tests would depends on certain kernel different configs. > > Imageing we have 100 test suite for kernel, how could you know which kernel > config is for which test suite, for examples, you add 50 kernel test suites > in the "TEST_SUITES", you end up finding that most of the kernel configs are > not enabled > you got 49 failure. > > so we'd better to eanble the test configs automatically, for example, test_A > required CONFIG_XXX, CONFIG_XXX sould be automatically enabled if (only if) > test_A is in your test plan (TEST_SUITES) . > > Lei Yes, agree with you. Your suggestion is our final goal. But now, CONFIGs and testcases are not sorted out completely, which we are going to do next. So we plan to perfect this stage by stage. And adapting this patch by upstream is good for us to implement remaining work. HongZhi
https://patchwork.openembedded.org/patch/151406/ https://patchwork.openembedded.org/patch/151407/
The issue has been resolved in 2.6. http://git.openembedded.org/openembedded-core/commit/?id=4af22800a7af4fcb80cafe08d982a4850d9dd2ad