dell
Automatically detecting compiler & linker used by kernel
Automatically choose the specific version of the compiler and linker used to compile the kernel
It's ready. I originally wanted to support the icc compiler too, but found that the classic icc is already deprecated and will be removed within this year, and the kernel also intends to drop its support.
Crazy idea - instead of going great lengths to add auto-detection of the compiler and linker, would it make more sense to allow people override it via a configuration file - be that the dkms.conf or per-module one?
Edit: Motivation being is that the heuristics or their ordering even can vary from one distribution to another. Even for seemingly close forks/derivatives (say Mint, Ubuntu, Debian or Devuan) - that can be significant.
Moving that to a config will scale better by shifting the focus to the respective distribution to manage their own platform quirks. It won't affect dkms maintenance nor execution - no point in checking through all the quirks if your system is vanilla.
This patch is mainly for the convenience of those who have kernels compiled with different compilers, like the one in #295. They don't need to create different config files for each kernel or compiler.
Edit: Motivation being is that the heuristics or their ordering even can vary from one distribution to another. Even for seemingly close forks/derivatives (say Mint, Ubuntu, Debian or Devuan) - that can be significant.
This patch mainly depends on CONFIG_CC_IS_XX and CONFIG_XX_VERSION in the kconfig file. Both of them were introduced with kernel 4.18, so the patch should meet the needs of most people today. Other detecting code is only for backward compatibility.
Moving that to a config will scale better by shifting the focus to the respective distribution to manage their own platform quirks. It won't affect dkms maintenance nor execution - no point in checking through all the quirks if your system is vanilla.
This patch doesn't rely on many distribution-specific quirks. If the kernel is compiled by gcc version a.b.c or clang version x.y.z, it only requires the presence of a executable named gcc-a.b.c / gcc-a.b / gcc-a or clang-x.y.z / clang-x.y / clang-x. If none of those files exist, then fall back to using gcc or clang without a version number. Even for distributions that do not adopt this "compiler-version" naming scheme, users still can let dkms choose the correct compiler by just creating a symbolic link or a wrapper script, as what I suggested in #299.
If I understand correctly the link/wrapper doesn't scale when using autoinstall. Particularly people will have various kernels each compiled with a different compilers/version, so a single wrapper doesn't sound feasible.
Am I missing something?
If I understand correctly the link/wrapper doesn't scale when using autoinstall.
In fact, the current autoinstall() implementation only supports building modules for one kernel, either the current kernel or the one specified by the command line argument -k.
If using dkms autoinstall --all, dkms will fail to build any modules even without this patch. This is because the autoinstall action dose not provide the module name & version to dkms, and dkms need these information to find kernels.
https://github.com/dell/dkms/blob/ce3e217f7d3746ab23cedf86613f636780b23a72/dkms.in#L259-L273
This is another bug worth a separate pull request IMO.
Particularly people will have various kernels each compiled with a different compilers/version, so a single wrapper doesn't sound feasible.
Yes, the user may need to create multiple link/wrapper, each one for a specified version of a compiler/linker. But because the new version of the compiler is usually released less frequently than the kernel, so I think it is more convenient to create link/wrapper for the compiler version than for the kernel version for people who have such a need.
After a closer look - I absolutely love the PR. There are a handful of small comments and it will be perfect.
Had a look for the various CONFIG symbols and when they are introduced:
CC_IS_GCCGCC_VERSIONCC_IS_CLANGCLANG_VERSION- 4.18.0LD_VERSION- 5.7LD_IS_LLD- 5.8 - initial implementation seems broken. usesgrep -q LLD, while the actual string is lowercaseCONFIG_CC_VERSION_TEXT- 5.8LLD_VERSION- 5.10LD_IS_BFD- 5.12
From the above, is seems that the CONFIG_CC_VERSION_TEXT fallback is of limited use - gcc/clang version fields predate and are consistently handled. Sadly LD handling is all over the place :-(
Most distributions in our matrix are 4.18+ with the odd ones - Centos 7 (3.10), Ubuntu 18 (4.15).
Checking the vmlinux .comment output on my Arch kernel - there are no linker details, only gcc note identical to CONFIG_CC_VERSION_TEXT.