Options manually spotted vs options auto inferred: confrontation

[arnobl]

First, I take the 10 most 'important' options (according to the inferred ones) and I look whether I had spotted them:

1. DEBUG_INFO: yes.

2. RANDOMIZE_BASE: no. I looked at the doc (https://cateee.net/lkddb/web-lkddb/RANDOMIZE_BASE.html) and it provides no information related to the kernel size.

3. DEBUG_INFO_REDUCED: yes.

4. DEBUG_INFO_SPLIT: yes.

5. STRICT_MODULE_RWX: no. One-line documentation (https://cateee.net/lkddb/web-lkddb/STRICT_MODULE_RWX.html). No information about size. However, the name of the option may be interpreted as the addition of a new module (so enlarges the kernel code base).

6. BLK_MQ_PCI: no. No documentation. https://cateee.net/lkddb/web-lkddb/BLK_MQ_PCI.html

7. MODULES: no. https://cateee.net/lkddb/web-lkddb/MODULES.html No reference to kernel size. Explains that the kernel with be built as a set of modules.

8. UBSAN_SANITIZE_ALL: yes.

9. X86_NEED_RELOCS: no. No documentation. https://cateee.net/lkddb/web-lkddb/X86_NEED_RELOCS.html

10. KASAN: no. https://cateee.net/lkddb/web-lkddb/KASAN.html. It adds a debugger to the kernel. No explicit reference to enlarging the code base but if adds something, it should enlarge.

[arnobl]

Options 11 to 20:

11. FB_SVGALIB: no. https://cateee.net/lkddb/web-lkddb/FB_SVGALIB.html Adds functions to drivers. So implicitly enlarges the kernel.

12. MDIO_DEVICE: no. https://cateee.net/lkddb/web-lkddb/MDIO_DEVICE.html. One line documentation. Seems to add drivers.

13. UBSAN_ALIGNMENT: no. One line documentation. https://cateee.net/lkddb/web-lkddb/UBSAN_ALIGNMENT.html No reference to size.

14. KASAN_OUTLINE: yes.

15. GCOV_PROFILE_ALL: yes.

16. ARCH_MIGHT_HAVE_ACPI_PDC: no. https://cateee.net/lkddb/web-lkddb/ARCH_MIGHT_HAVE_ACPI_PDC.html No documentation.

17. SWPHY: no. https://cateee.net/lkddb/web-lkddb/SWPHY.html No documentation

18. INTEL_GTT: no. https://cateee.net/lkddb/web-lkddb/INTEL_GTT.html. No documentation.

19. DST_CACHE: no. https://cateee.net/lkddb/web-lkddb/DST_CACHE.html. No documentation.

20. XFS_DEBUG: yes.

[arnobl]

Second, I compared (python script) the options I spotted manually and the ones auto inferred.
I produced a csv file that associates each optional I spotted with its computed importance value:
optionsAndImportance.csv.
21 out of the 133 options I spotted have an importance value.

[arnobl]

Possible threats to discuss:

• I am not a Linux expert, so I cannot detect options that have an implicit impact on the kernel size
• The XP protocol I use has failures
• the initial data set of Hugo biases the results (eg one option is never used)
• The XP protocol Hugo uses has failures
• we cheated the ML tool. Example: option B uses option A. Options C uses option A. Options B and C have an impact on the kernel size. So, the ML tool detect that A has a strong impact on the kernel size (while it is not the case).

[arnobl]

On the 20 first options:

• 6 options do not have documentation
• 4 options have documentation that may enlarge the kernel code base (so may enlarge the kernel size implicitly). No obvious and may be error prone.
• 3 options have documentation that do not talk about size

[FAMILIAR-project]

It should be noted that
pearsonr(df['MODULES'], df['STRICT_MODULE_RWX'])[0] gives 1
(the two variables are correlated: they have same values in all configurations)

Implication:

• it's strange that both appears in the list (the learning could be better or we should help to avoid this situation)
• in terms of interpretability we have to be careful about this well-known phenomenon (some options are correlated to others)