[lkml]   [2000]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: /dev/cpu/*/(cpuid, msr) unhappy as modules - OOPS!
> 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",
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

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.)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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