lkml.org 
[lkml]   [2008]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 05/11] [PATCH 05/11] x86: Moved microcode.c to microcode_intel.c.

    * Peter Oruba <peter.oruba@amd.com> 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.

    yes - as long as the internal abstraction is clean (and it is rather
    clean with Dmitry's changes applied too), that should be fine and
    maintainable.

    Ingo


    \
     
     \ /
      Last update: 2008-09-20 08:11    [W:0.023 / U:1.096 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site