> 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
