Re: [patch 05/11] [PATCH 05/11] x86: Moved microcode.c to microcode_intel.c.

["Giacomo A. Catenazzi" <cate@debian.org>]

Peter Oruba wrote:
> Giacomo A. Catenazzi schrieb:
>> Dmitry Adamushko wrote:
>>> 2008/9/19 Peter Oruba <peter.oruba@amd.com>:
>>>> Some additonal words regarding the current user space issues:
>>>>
>>>> IMHO the most convenient way to update microcode is through the
>>>> firmware loading
>>>> interface instead of microcode_ctl. This reduces user-space
>>>> responsibilities to
>>>> loading the correct module at boot time and to place the microcode
>>>> patch file at
>>>> the right location via package installation. The problems mentioned
>>>> in this
>>>> thread would then probably disappear as well. What do you guys think?
>>> It'd still require changes for all the setups that currently rely on
>>> the 'microcode_ctl' interface. Moreover, Arjan's setup failed not due
>>> to the 'microcode_ctl' per se but due to the altered kernel module
>>> name. After all, we can't break the established interface this way.
>>>
>>> We can either reserve 'microcode' as a legacy name for intel cpus (==
>>> microcode_intel), or maybe we can use request_module() from
>>> microcode.ko to load a proper arch-specific module (I guess, it's not
>>> ok for !KMOD-enabled kernels).
>> I agree. A wrapper "microcode.ko" module would be nice, in order
>> to allow independent kernel and user space upgrades.
>>
>> The module name is important also on udev method: only a module
>> load triggers the microcode request in udev, thus also the
>> new method should have stable kernel module name.
>>
>> ciao
>>     cate
>>
> 
> That sounds like a single-module solution would be the best way to go. All
> dependencies would then be handled inside the module.

Single module probably is more difficult to maintain.

I was thinking about a very simple additional module:
It checks the cpu: load the relevant module, and wrapper the
calls to the relevant module.

So every vendor could develop easier the own driver. Only the interface
should be stable.

Eventually we could solve it in the distribution scripts (using module
aliases), but it would be kernel version dependent, and it would works
only on the new method (or a new microcode_ctl version, but people
upgrade more often kernel than packages).

ciao
	cate