kar schrieb
Bisher wurden die Microcodes über das Paket "linux-firmware" ausgeliefert und jetzt wurden sie in das neue Paket verpackt.
Eben nicht; sie wurden bislang mit dem Kernel als Kernelmodul microcode.ko.gz ausgeliefert und jetzt als Image in einem neuen Paket.
Wenn ich jetzt also nach der Logik "Warum etwas, was problemlos funktioniert veraendern?" vorgehen will, muss ich mir also das neue Paket "intel-ucode" installieren und meinen Bootloader entsprechend anpassen?!
Das ist ja eben die Frage, ob es wirklich immer und bei jedem in der Vergangenheit problemlos funktionierte. Scheinbar nicht, sonst hätte man sich nicht dazu entschlossen, den Microcode in den Bootvorgang vorzuziehen.
Aber warum wurden die Intel-Microcodes dann überhaupt in ein eigenes Paket ausgelagert? Wurde das von Intel gefordert oder hat es andere Gründe? Vielleicht Lizenz-Rechtliche Probleme bzw. Unstimmigkeiten?
OK, das hatte ich ja weiter oben auch schon in Frage gestellt, warum man das Image nicht im Kernelpaket lassen konnte. Lizenzrechtliche Gründe halte ich für ausgeschlossen weil ja einerseits der Microcode von Intel und für Linux öffentlich auf deren Website angeboten wird und zum anderen nur eine Verschiebung unter den verschiedenen Paketen stattgefunden hat; das löst keine Lizenzprobleme.
Der einzige plausible Grund für mich ist eigentlich nur, dass man nicht für beide Prozessorhersteller Intel und AMD in einem Kernel gemeinsam zwei Images aufnehmen wollte von denen eines dann immer und garantiert nicht benötigt würde. Unter /boot hätte man dann zwei Images mit verschiedenen Bezeichnungen, von denen man dann das richtige in den Bootloader aufnehmen müsste. Wie man das mit dem bis jetzt gemeinsam genutzten Kernelmodul gemacht hat weiß ich auch nicht, jedenfalls ist das Modul "microcode" unter Kernel-3.16 noch geladen.
Aber das ist auch nur eine Vermutung, besonders viel erfährt man ja zu dem Thema nicht.