Consolidation of kernel module names (e.g. coretemp vs. amdtemp)

[Mjölnir]

Before posting a bug report labeled as [request], I'd like to hear your opinions to lift the quality of my bug report as high as possible.
This is my DRAFT, that you may kindly enhance:

STATUS: For the amd64 CPU architecture, there are at least two kernel modules with different names to report the CPU temperature, and for other architectures the corresponding modules likely have different names. To load them, you have to use the correct name.

EXPECTED: It would be advantageous not only for the human sysadmin, but for automated administration and scripts as well, to be able to load the right module for a given topic under one consolidated name if more than one modules exist which satisfy the same requested "service". E.g. I'd like to load cputemp(4) that loads the right kernel module according to the CPU architecture.

HINT: Maybe this is best solved by a meta-loader support module, since this problem does not only affect the aforementioned temperature reporting modules. I.e. the module-loading logic uses this supporting meta-loader to find the kernel module that matches the requested "service" best. Then the meta-module cputemp would be virtual, i.e. it's just a name that is known by the meta-loader.

 

[SirDice]

Maybe this is best solved by a meta-loader support module, since this problem does not only affect the aforementioned temperature reporting modules. I.e. the module-loading logic uses this supporting meta-loader to find the kernel module that matches the requested "service" best. Then the meta-module cputemp would be virtual, i.e. it's just a name that is known by the meta-loader.

The meta-loader can simply load the correct kernel module. Similarly to snd_driver (which loads every available snd_* driver), but maybe with some added logic to only load the appropriate kernel module? Not sure if the logic is possible, it might be fine to simply load everything.

 

[mer]

For AMD64, I only see coretemp.ko and amdtemp.ko in /boot/kernel. Are there others?
Is it "coretemp is for Intel CPUs and amdtemp is for AMD CPUs"?
Or can you run coretemp on AMD and amdtemp on Intel?

Where is cputemp coming from? Asking because your link doesn't work. Is it a port? Does it have kmods?

I've always added the correct "temp" kmod in my rc.conf so it's always available for userland.

I'm not disagreeing with the underlying premise, but I fail to see the "problem"

 

[Mjölnir]

[...] it might be fine to simply load everything.

Why waste precious memory? Even if the memory for the modules is labeled as "file-backed by an immutable file", i.e. it does not need swapspace because it's immutable, any unused module loaded still comsumes some kernel metadata, since the kernel needs to remember which modules were loaded, where to find them etc.pp. This may sound picky, but remember that a general-purpose kernel might run on an embedded device with much less RAM than we have in our desktops and laptops.

For AMD64, I only see coretemp.ko and amdtemp.ko in /boot/kernel. Are there others?

I'm not aware of any other. That's why I wrote "at least two".

Is it "coretemp is for Intel CPUs and amdtemp is for AMD CPUs"?

Yes.

Or can you run coretemp on AMD and amdtemp on Intel?

IDK and IDTS

Where is cputemp coming from? Asking because your link doesn't work. Is it a port? Does it have kmods?

No, this is my "invention", i.e. this would be the name of a virtual module to load the correct kernel module depending on the environment. The environment is very likely the CPU architecture in most cases, but I I could think of other criteria, e.g. in virtualized (cloud) scenarios. In my example, this module would not exist as a file, but simply be a name that the more or less smart meta-loader knows of. I.e. it knows what to do when it is feeded with this name in the given environment. This might in principle be the same problem that is already solved by make(1), but maybe there are important differences. Let's find out during the discussion.

I've always added the correct "temp" kmod in my rc.conf so it's always available for userland.

Yes, but you have to use a different name on your AMD and Intel machines, although it would be possible -- and I expect that such a simple plroblem can easily be solved in these days when AI is able to solve problems that are much more complicated -- that you have the same configuration for all your machines, regardless of the hardware. You should be able to write kld_list="$[kld_list} cputemp" in your rc.conf(5) on ANY machine, be it AMD, Intel, RISC V, ARM or whatever.

I'm not disagreeing with the underlying premise, but I fail to see the "problem"

You would see the problem if you had to administer a cluster of 20 thousand heterogenous machines.