Open douglas-raillard-arm opened 9 months ago
Given the behavior of current Android GKI kernels, we cannot rely on =N meaning the feature is not available in a module, as the module may still be available (/proc/config.gz can lie in this way in Android apparently due to the way GKI build system works as reported by @patrik-arm). Therefore, the behavior we want is:
If the mapping config<->module name is not know for the feature, the function should raise an exception. It might be a good idea to allow the user to pass an expected module name so they can work around an incomplete mapping provided by devlib.
Since this is definitely a bug in Android, maybe we should check for the target type and use the sane behavior (=N means it's not available) on non-android targets, but that may mean some code working on mainline kernel would break on android targets, whereas having a single path working for the buggy case will ensure user code works in both cases.
Code sometimes need to check if some kernel config options is enabled. For a lot of them, checking they are =y is actually stricter than necessary, but allowing =m means the check can succeed without the feature being actually available if the corresponding module was not loaded.
To alleviate that, we could have a
Target.ensure_kconfig()
method that:Unfortunately, there is no generic way of knowing the module name associated with a given kconfig, so the mapping has hard coded. However, we can have a maintenance script that finds a mapping for a given kernel source tree by looking for
obj-$(CONFIG_FOO) += the module.o anothermodule.o
and merge the result with the existing mapping in devlib.