Re: [PATCH 3/4] kbuild: slim down package for building external modules

Jeffrey Hugo
2025-02-28T22:04:39Z

On 2/20/2025 10:43 AM, Greg KH wrote:
> On Thu, Feb 20, 2025 at 10:24:32AM -0700, Jeffrey Hugo wrote:
>> On 2/20/2025 9:49 AM, Greg KH wrote:
>>> What do you need/want to parse the .config file in the first place? Why
>>> not rely on the generated .h files instead as those can be parsed the
>>> same way as before, right?
>>
>> Two usecases -
>>
>> First when secure boot is enabled, DKMS looks for CONFIG_MODULE_SIG_HASH to
>> figure out signing the modules so that they can be loaded. Removing .config
>> causes an error in DKMS and the module signing process will fail. The
>> resulting modules (already compiled successfully) will fail to load.
>> Whatever the user needed those modules for will no longer work.
>
> Shouldn't the "normal" kbuild process properly sign the module if it
> needs to be signed? Or are you trying to do this "by hand"?
>
>> If the user is on Ubuntu, and has built a kernel 6.12 or later, they need to
>> build upstream DKMS and use it as none of the Canonical provided DKMS builds
>> have the fix. This feels like a situation that would make the user afraid
>> to upgrade their kernel (to your point above).
>>
>> This feels very much like an "at runtime" issue, assuming external modules
>> are supported. I may be wrong here.
>
> external modules can be broken at any moment in time, you know that.
> There's never a guarantee for that at all.
>
>> Second, our usecase is that we look at the .config to tell if a particular
>> driver is included in the kernel build (config =y or =m). This driver
>> provides diagnostic information which is useful to our product, but not
>> required for operation. It does not have headers that are exposed to the
>> rest of the kernel, so checking the generated .h files does not work. If
>> the driver is not built, we provide a backported version that is then built
>> out of tree.
>
> You can check the same .h files for those config options, no need to
> manually parse a .config file. What's wrong with including
> include/generated/autoconf.h properly? That's what the build system
> uses, right?

I can't check .h files that don't exist.

However, I think your viewpoint is coming through pretty clear - we'll
fix up what we can in our control, and I guess anything else gets
dropped on the floor. Seems like I have a conclusion.

-Jeff