lkml.org 
[lkml]   [2000]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: /dev/cpu/*/(cpuid, msr) unhappy as modules - OOPS!
Date
> Looks like a devfs problem; complain to the appropriate people.  I refuse 
> to touch that particular devfs code.

I've had a quick look at both the 2.2.18 and 2.4.0-test12 drivers for
msr and cpuid, and I've noticed something curious.

This is the comment from 2.4.0-test12, cpuid.c:

/*
* cpuid.c
*
* x86 CPUID access device
*
* This device is accessed by lseek() to the appropriate CPUID level
* and then read in chunks of 16 bytes. A larger size means multiple
* reads of consecutive levels.
*
* This driver uses /dev/cpu/%d/cpuid where %d is the minor number, and on
* an SMP box will direct the access to CPU %d.
*/

And this is the initialisation function:

int __init cpuid_init(void)
{
if (register_chrdev(CPUID_MAJOR, "cpu/cpuid", &cpuid_fops)) {
printk(KERN_ERR "cpuid: unable to get major %d for cpuid\n",
CPUID_MAJOR);
return -EBUSY;
}

return 0;
}

These two are inconsistent! I had dutifully created a /dev/cpu/0
directory on my 2.2.18 and 2.4.0-test12 boxes, and had placed cpuid
device nodes inside them. (The 2.4.0-test12 box is SMP, and so I also
created a /dev/cpu/1 directory there too.) However, the driver expects
the device node to be /dev/cpu/cpuid. The msr driver has the same
problem.

Both the cpuid and the msr modules successfully loaded on 2.2.18 when
I tried to cat /dev/cpu/cpuid and /dev/cpu/msr. (Although they both
remained flagged as (unused), which I found strange considering the
amount of output I got.)

Cheers,
Chris



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.045 / U:4.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site