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.

 

[mer]

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

Fair point, but if at creation time of each machine, the configuration was set to load the correct thing, then doesn't it become a moot point?

As for "having the same configuration for all your machines" valid, but you would need to extend that to any potential kmod that may be different. snd driver is an example of this. Currently "loads them all and uses only one" instead of "figuring out which one to load and use"

You point out AI doing stuff, well if one is trying to keep the same configs, why not have generation of the config test the hardware and set the config correctly for the machine? Lots of installs do this.

 

[Mjölnir]

As for "having the same configuration for all your machines" valid, but you would need to extend that to any potential kmod that may be different. snd driver is an example of this. Currently "loads them all and uses only one" instead of "figuring out which one to load and use"

IIUC this wastes memory. Maybe not much, but it could be zero waste if only the neccessary modules were loaded.

You point out AI doing stuff, well if one is trying to keep the same configs, why not have generation of the config test the hardware and set the config correctly for the machine? Lots of installs do this.

When you change some hardware, e.g. the soundcard, this test needs to run again and increases the boot time. Why do modern UEFI machines need longer to boot than much less powerful machines needed 30 years ago? Because they test the hardware on every power up cycle...

 

[hedwards]

IIUC this wastes memory. Maybe not much, but it could be zero waste if only the neccessary modules were loaded.

When you change some hardware, e.g. the soundcard, this test needs to run again and increases the boot time. Why do modern UEFI machines need longer to boot than much less powerful machines needed 30 years ago? Because they test the hardware on every power up cycle...

Longer? My UEFI machines boot significantly faster than they did back then. Anyways, that's going to depend a lot on the specific system, the UEFIs seem to hit stuff on the disk more than they did back then as well as doing a bunch of stuff that was flat out not possible back then

As far as extra drivers go, that's historically been why people compiled their own kernel to remove things they weren't using. I don't personally bother these days unless I have some change that requires it, but it remains a possibility.

 

[Mjölnir]

Longer? My UEFI machines boot significantly faster than they did back then.[...]

Hm, maybe I have to look into the UEFI settings and search if I can disable these loooong tests?
Until your posting I thought this is normal, because both of my UEFI machines are very snoozy after power on. A warm boot is fast, yes, unsurprisingly much faster than 30 years ago because the hardware is more powerful.

 

[hedwards]

Hm, maybe I have to look into the UEFI settings and search if I can disable these loooong tests?
Until your posting I thought this is normal, because both of my UEFI machines are very snoozy after power on. A warm boot is fast, yes, unsurprisingly much faster than 30 years ago because the hardware is more powerful.

I'd have to time it, and keep in mind that it's not a particular apples to apples comparison. It seems to get to the point where I've got the BSD loader screen in a couple seconds and the longest part of the boot process is when I have to tell zfs to mount because of issues with the boot process that I can't be bothered to address.

If UEFI is taking more than a few seconds to hit the loaderscreen, then there's something weird about your machines because I don't think I've used a system in quite a few years that took as long as the BIOS did to start actually booting.

EDIT, it does take a few seconds, but by far the thing that takes rebooting the longest is unmounting the disks and dealing with the jails on my system. The few seconds of UEFI stuff is something that I would have gladly traded for the boot times i was getting in the '90s and '00s.