That is, calling the script for the three parameters (gcc version, kernel version, ways of picking a configuration) should give something.
Docker should be used to host the necessary tools (compilers as well as kci tool suite).
I'm expecting a functional demonstration ASAP. "Functional" means that some results are produced.
The dev is actually in another repo: https://github.com/TuxML/tuxml-kci
Then, to further test the script, we should compare it with tuxml (without kci).
Conceptually, tuxml and tuxml-kci actually implement the same functionnaly ksize (c, kv, cc) = bz (see above)
So an experiment for testing is to check that for the same configuration, kernel version, and compiler version, we have the same build status and same binary size.
This experiment should be done on several configurations and kernel versions that already exist in the database (data made with tuxml).
A script can automate the testing by simply calling tuxml-kci, gathering the results, compare and conclude.
That is, calling the script for the three parameters (gcc version, kernel version, ways of picking a configuration) should give something. Docker should be used to host the necessary tools (compilers as well as kci tool suite).
I'm expecting a functional demonstration ASAP. "Functional" means that some results are produced. The dev is actually in another repo: https://github.com/TuxML/tuxml-kci
Then, to further test the script, we should compare it with tuxml (without kci). Conceptually, tuxml and tuxml-kci actually implement the same functionnaly ksize (c, kv, cc) = bz (see above) So an experiment for testing is to check that for the same configuration, kernel version, and compiler version, we have the same build status and same binary size. This experiment should be done on several configurations and kernel versions that already exist in the database (data made with tuxml). A script can automate the testing by simply calling tuxml-kci, gathering the results, compare and conclude.