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.
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
01-08-2012, 08:05 PM
Dave Reisner
Reorganizing CPU ucode updates
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/microcode
> [2]
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/?h=packages/amd-ucode
>
Awesome.
I opt for consistency -- call the packages amd-ucode and intel-ucode.
d
01-08-2012, 08:34 PM
Tom Gundersen
Reorganizing CPU ucode updates
On Sun, Jan 8, 2012 at 9:50 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> 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.
Reorganizing CPU ucode updates
