[arch-dev-public] Reorganizing CPU ucode updates
After some talk on IRC with Tom and Dan, I created new ucode packages. This is the plan so far: 1) Drop microcode_ctl - this Intel-only tool used the microcode.dat file provided by Intel to update the ucode. 2) Add the split firmware files in /lib/firmware/intel-ucode in a new package ([1]). 3) Add the AMD firmware file in /lib/firmware/amd-ucode in a new package ([2]). With this setup, a user simply needs to add the 'microcode' module in rc.conf, and the ucode update will be applied automatically. As Tom tells me, future linux versions will even autoload microcode when appropriate. One issue is package naming: We could stick with the usual "source tarball == package name" paradigm, but that means that the Intel package is named 'microcode', while the AMD package is named 'amd-ucode' (like it is commited to SVN now). I would prefer calling the Intel package 'intel-ucode', which would be consistent with the AMD version and also match the name of the /lib/firmware/ subdirectory. Please throw opinions at me. [1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/?h=packages/... [2] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/?h=packages/...
On 08.01.2012 21:50, Thomas Bächler wrote:
With this setup, a user simply needs to add the 'microcode' module in rc.conf, and the ucode update will be applied automatically. As Tom tells me, future linux versions will even autoload microcode when appropriate.
Sounds awesome. I actually never bothered setting up microcode updates on my boxes. Does it help at all? (performance, bugs, whatever)
One issue is package naming: We could stick with the usual "source tarball == package name" paradigm, but that means that the Intel package is named 'microcode', while the AMD package is named 'amd-ucode' (like it is commited to SVN now). I would prefer calling the Intel package 'intel-ucode', which would be consistent with the AMD version and also match the name of the /lib/firmware/ subdirectory.
What about intel-ucode (with a provides=microcode) and amd-ucode? That way pacman -S microcode will work as expected and the package will have the correct name. -- Florian Pritz
On Sun, Jan 08, 2012 at 09:50:47PM +0100, Thomas Bächler wrote:
After some talk on IRC with Tom and Dan, I created new ucode packages. This is the plan so far:
1) Drop microcode_ctl - this Intel-only tool used the microcode.dat file provided by Intel to update the ucode.
2) Add the split firmware files in /lib/firmware/intel-ucode in a new package ([1]).
3) Add the AMD firmware file in /lib/firmware/amd-ucode in a new package ([2]).
With this setup, a user simply needs to add the 'microcode' module in rc.conf, and the ucode update will be applied automatically. As Tom tells me, future linux versions will even autoload microcode when appropriate.
One issue is package naming: We could stick with the usual "source tarball == package name" paradigm, but that means that the Intel package is named 'microcode', while the AMD package is named 'amd-ucode' (like it is commited to SVN now). I would prefer calling the Intel package 'intel-ucode', which would be consistent with the AMD version and also match the name of the /lib/firmware/ subdirectory.
Please throw opinions at me.
[1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/?h=packages/... [2] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/?h=packages/...
Awesome. I opt for consistency -- call the packages amd-ucode and intel-ucode. d
On Sun, Jan 8, 2012 at 9:50 PM, Thomas Bächler
One issue is package naming: We could stick with the usual "source tarball == package name" paradigm, but that means that the Intel package is named 'microcode', while the AMD package is named 'amd-ucode' (like it is commited to SVN now). I would prefer calling the Intel package 'intel-ucode', which would be consistent with the AMD version and also match the name of the /lib/firmware/ subdirectory.
I agree with using intel-ucode, having them named differently would be confusing. -t
participants (4)
-
Dave Reisner
-
Florian Pritz
-
Thomas Bächler
-
Tom Gundersen