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

[Jeffrey Hugo <quic_jhugo@quicinc.com>]

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