On Sat, Dec 07, 2024 at 12:50:47AM +0530, BiscuitBobby wrote: > On Thu, 5 Dec 2024 at 21:05, Mark Brown <broonie@xxxxxxxxxx> wrote: > > If people are building the selftests once and then using them > > with a bunch of kernel builds it might be surprising if some of the > > binaries vanish. > I'm not really familiar with packaging selftests, but this patch does not > remove existing binaries when running tests. If I misunderstood what > you are referring to, please let me know. It doesn't remove existing barriers but it's also not obvious that this isn't just a generic dependency mechanism that should be used for any old dependency rather than things that would actually break the build, and it's one config list for both build and runtime checks. If the intention is that this should be infrequently used it probably needs to be a bit clearer that that's the case. As things stand I'd expect there to be some confusion about the interaction between this and the existing system with specifying config fragments. > > Shouldn't we try the current kernel tree, and for runtime checks > > /proc/config.gz would be good to check when it's enabled? > When I looked into this, it seems (according to the config.gz man page) > that the contents of /proc/config.gz are the same as > /lib/modules/$(uname -r)/build/.config, but /proc/config.gz is only available if > the kernel was compiled with CONFIG_IKCONFIG_PROC enabled. > It does seem like /lib/modules/$(uname -r)/build/scripts is not always available > though, so will send in a new patch directly checking build/.config > after checking > it out on a few more systems. Indeed, when deploying a kernel for test people don't always deploy modules onto the target filesystem, there may not be any modules at all if CONFIG_MODULES is disabled, or people might just not install modules that do get built if they're not needed on a given platform.
Attachment:
signature.asc
Description: PGP signature
