The unstable microcode-data ebuilds (starting with 20110915-r1) currently double as the old-style init.d-loadable /lib/firmware/microcode.dat, and the new-style kernel-loadable /lib/firmware/intel-ucode (mirroring amd-ucode). Other distributions (e.g., Arch Linux) have moved to intel-ucode exclusively, removing the often buggy microcode_ctl altogether (https://wiki.archlinux.org/index.php/Microcode). I suggest creating a separate sys-kernel/intel-ucode ebuild that: * installs only /lib/firmware/intel-ucode, not /lib/firmware/microcode.dat * depends on !sys-apps/microcode-data * has a recommendation to add "microcode" to /etc/conf.d/modules in pkg_postinst * deprecates sys-apps/microcode-ctl and sys-apps/microcode-data
Created attachment 312689 [details] sys-kernel/intel-ucode-20111110.ebuild This ebuild is based on sys-apps/microcode-data-20111110 and on sys-kernel/amd-ucode. It requires files/intel-microcode2ucode.c from sys-apps/microcode-data.
Honestly I'm not happy about a move like this, while I'm the first who's been hoping to get the split ucode [1], microcode.dat is not much bigger, and replacing a whole ebuild with something that might or might not work right now doesn't feel like a good idea. But others can chime in of course. [1] http://blog.flameeyes.eu/2011/01/microupdates-for-microcodes
Diego, I read your blog entry, but got confused towards the end. Don't microcode.dat and the individual files produced by intel-microcode2ucode contain exactly the same entries? # find /lib/firmware/intel-ucode -type f | wc -l 68 # grep '\.inc' /lib/firmware/microcode.dat | wc -l 137 It would seem that microcode.dat doubles the number of entries for some reason, and there is one additional entry -- is that additional entry what you mean by "the driver also has the ability to parse the generic microcode compiled from microcode.dat, and then find the right version for the right processor"? > replacing a whole ebuild with something that might or might not work right now doesn't feel like a good idea Well, you can certainly see the firmware load attempts. I remember looking at kernel sources before filing this bug report, and the Intel-related code simply forms a CPU signature and tries to load the firmware file. There is not much possibility of it not working, I think -- either the relevant firmware is present, or isn't. The main motivation for going with the intel-ucode approach, as I see it, is ability to boot same distribution on different architectures. On non-Intel CPUs, microcode_ctl will fail. It is the same motivation that drives many other hot-plugging capabilities (e.g., rc_hotplug="bluetooth pcscd") -- you only load what you need. If the kernel provides this capability -- why not? And this capability is very robust -- that's how all device firmware gets loaded, for instance, as you noted in the blog post.
What I mean is that it requires a more proper configuration: to be able to load the ucode from the kernel, the microcode patch loading has to be in a module (I tried, it doesn't seem to get it right on my laptop otherwise), while microcode_ctl works fine on monolithic kernels (which are still used for instance in embedded or server configurations). Given that the only downside of keeping it this way is installing one more file and having one more dependency, I don't see a compelling reason to change it yet.
Created attachment 319362 [details] sys-kernel/intel-ucode-20120606.ebuild version bump, based on sys-apps/microcode-data-20120606
Maybe install microcode.dat with a USE-flag?
Comment on attachment 319362 [details] sys-kernel/intel-ucode-20120606.ebuild (1) we don't want to maintain multiple ebuilds (2) please post *patches*, not entire files (3) let's go with a USE flag in the existing ebuild (e.g. IUSE=+monolithic)
Created attachment 350296 [details, diff] monolitic use patch for microcode-data-20130222.ebuild Here is a patch against latest microcode-data ebuild. I personally think that this package must be renamed to intel-ucode and monolitic use flag switched off by default. I spent about 10 minutes before found intel cpu firmware in portage
(In reply to nE0sIghT from comment #8) > Created attachment 350296 [details, diff] [details, diff] > monolitic use patch for microcode-data-20130222.ebuild This patch is suitable for the new version - microcode-data-20130906.ebuild
Let me work on this. The patch looks good. I will also rename microcode-data to sys-firmware/intel-ucode.
(In reply to nE0sIghT from comment #9) > (In reply to nE0sIghT from comment #8) > > Created attachment 350296 [details, diff] [details, diff] [details, diff] > > monolitic use patch for microcode-data-20130222.ebuild > > This patch is suitable for the new version - microcode-data-20130906.ebuild Same changes works well with sys-apps/microcode-data-20140122
Created attachment 379904 [details, diff] monolitic use patch for microcode-data-20140624.ebuild Patch for new version.
Created attachment 385292 [details, diff] monolitic use patch for microcode-data-20140913.ebuild
Same changes works well with sys-apps/microcode-data-20150121
i've added dedicated USE flags to microcode-data-20150121-r1: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df93befac0d0267d671f384e43447c0b016d777c
