From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754645AbYISM6y (ORCPT ); Fri, 19 Sep 2008 08:58:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752719AbYISM6n (ORCPT ); Fri, 19 Sep 2008 08:58:43 -0400 Received: from xsmtp1.ethz.ch ([82.130.70.13]:48587 "EHLO xsmtp1.ethz.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751728AbYISM6n (ORCPT ); Fri, 19 Sep 2008 08:58:43 -0400 Message-ID: <48D3A1FD.7010309@debian.org> Date: Fri, 19 Sep 2008 14:58:37 +0200 From: "Giacomo A. Catenazzi" User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Dmitry Adamushko CC: Peter Oruba , Arjan van de Ven , Ingo Molnar , Thomas Gleixner , Tigran Aivazian , LKML Subject: Re: [patch 05/11] [PATCH 05/11] x86: Moved microcode.c to microcode_intel.c. References: <20080728164411.490752571@amd.com> <20080728164448.492961653@amd.com> <20080907120823.59f8fa47@infradead.org> <48CA586C.2010104@amd.com> <20080912063517.783b7f85@infradead.org> <48D3942B.1050901@amd.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Sep 2008 12:58:40.0697 (UTC) FILETIME=[7065DA90:01C91A57] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dmitry Adamushko wrote: > 2008/9/19 Peter Oruba : >> 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