[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49B8DDDF.8080708@cateee.net>
Date: Thu, 12 Mar 2009 11:03:11 +0100
From: "Giacomo A. Catenazzi" <cate@...eee.net>
To: Arjan van de Ven <arjan@...radead.org>
CC: Sitsofe Wheeler <sitsofe@...oo.com>,
Dragoslav Zaric <dragoslav.zaric.kd@...il.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Linux* Processor Microcode Data File
Arjan van de Ven wrote:
> On Mon, 9 Mar 2009 15:34:50 +0000
> Sitsofe Wheeler <sitsofe@...oo.com> wrote:
>
>> On Mon, Mar 09, 2009 at 08:11:09AM -0700, Arjan van de Ven wrote:
>>> On Mon, 9 Mar 2009 14:16:55 +0000
>>> Sitsofe Wheeler <sitsofe@...oo.com> wrote:
>>>
>>>> The kernel doesn't load microcode automatically
>>> it does if you have the right format; the kernel uses
>>> request_firmware() for this.
>>> The microcode on the intel website is not ready for this yet, but
>>> we're working hard to have future drops to be in the new format.
>> Wow so I was redundant AND wrong in the same email!
>>
>> What motivated the switch to the generic request_firmware interface?
>> Is it just less messy/faster than previous methods?
>
> there are various cases where microcode is needed (for example, when
> you hotplug a new cpu); request_firmware() is just the right way to do
> such things, and an initscript is just the wrong way
I don't agree ;-)
I agree that request_firmware method is better than init.d scripts, but
not that it is the right things. microcodes should be loaded at very
beginning of boot process, so by BIOS, by GRUB or on hotpug event by
request_firmware.
BTW: why do we have microcode loading modular?
Offtopic: IMHO if we could move the load of firmware before booting
linux, it would be nicer and cleaner (by open source point of view).
ciao
cate
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists