@ryannathans@captainkangaroo I’m going to make the wild assumption that the kernel will have a table of the current microcode versions at the time of it’s release, but I doubt that
will get updated except by kernel upgrades.
@ryannathans Why bloat the kernel with the microcode for every intel processor that might need it (and there is a similar thing for AMD) when you don’t have that specific processor? It does make more sense for it to be a separate, especially on memory constrained systems. I mean if you’ve got 256GB of RAM probably not a big deal but if you’ve got 256MB a big deal.
How does it know if the microcode is outdated?
@ryannathans @captainkangaroo I’m going to make the wild assumption that the kernel will have a table of the current microcode versions at the time of it’s release, but I doubt that
will get updated except by kernel upgrades.
Debian-based distros (and probably most othera as well) actually have a package called “intel-microcode” which gets updated fairly regularly.
There’s probably an efivar that reads the current microcode version.
If that’s the case, why wouldn’t they put the microcode in the kernel?
@ryannathans Why bloat the kernel with the microcode for every intel processor that might need it (and there is a similar thing for AMD) when you don’t have that specific processor? It does make more sense for it to be a separate, especially on memory constrained systems. I mean if you’ve got 256GB of RAM probably not a big deal but if you’ve got 256MB a big deal.
The kernel compilation is already configurable between megabytes and gigabyte+