lkml.org 
[lkml]   [2008]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2.6.24] x86: add sysfs interface for cpuid module
    Yi Yang wrote:
    > Current cpuid module will create a char device for every logical cpu,
    > when a user cats /dev/cpu/*/cpuid, he/she will enter a limitless loop,
    > the root cause is that cpuid module doesn't decide wether a cpuid level
    > is valid, it just uses an offset to denote cpuid level and take it to
    > cpuid instruction, cpuid instruction will ignore it and return some data
    > specific to cpu model, cpuid doesn't an error return value because it is
    > void type. So cpuid module will execute cpuid continuously and return
    > data although most of data make no sense.
    >
    > This patch tries to add a sysfs interface for cpuid, users can see all the
    > available cpuid levels, specify a specific level and get cpuid corresponding
    > to this cpuid level.
    >
    > For every logical cpu, this patch will create a cpuid directory under
    > /sys/devices/system/cpu/cpu*/, there are three entries under cpuid:
    >
    > avail_levels cur_level cur_cpuid
    >
    > A user can get all the available cpuid levels from avail_levels, he/she can
    > set one available cpuid level to cur_level, then he/she can get cpuid from
    > cur_cpuid, cur_cpuid corresponds to cur_level.
    >
    > This patch uses sysfs to avoid limitless loop and provide more flexible
    > interface for cpuid, please consider to merge to -mm tree in order to test.

    This is broken.

    Triple broken.

    It's broken, because it doesn't take into account the fact that Intel
    broke CPUID level 4 and made it "repeating" (neither did the cpuid char
    device, because it predated the Intel braindamage; I've had a patch for
    it privately for a while, but didn't push it upstream because paravirt
    broke it royally and I wanted the situation to settle down.)

    It's broken, because the algorithm used to determine valid CPUID levels
    is incorrect; it fails to recognize any CPUID levels other than the main
    Intel and AMD ones, e.g. the Transmeta 0x8086xxxx (and sometimes more)
    and VIA 0xc000xxxx levels.

    It's broken, because it is better for the userspace extractor to have
    this logic than to stuff it into the kernel, where it sits hogging
    unswappable memory at all times.

    -hpa


    \
     
     \ /
      Last update: 2008-01-29 16:59    [W:2.796 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site