FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 01-08-2012, 07:50 PM
Thomas Bächler
 
Default 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/microcode
[2]
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/?h=packages/amd-ucode
 
Old 01-08-2012, 08:04 PM
Florian Pritz
 
Default Reorganizing CPU ucode updates

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
 
Old 01-08-2012, 08:05 PM
Dave Reisner
 
Default 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
 
Old 01-08-2012, 08:34 PM
Tom Gundersen
 
Default 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.

-t
 

Thread Tools




All times are GMT. The time now is 12:49 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org