From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 Description of problem: /usr/include/asm/msr.h is not in glibc-kernheaders-2.4-7.14 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.do an ls of "/usr/include/asm/msr.h" 2.not there... 3. Additional info: My guess is that when you guys moved the kernel-header stuff over to glibc-kernheaders, you forgot to include asm/msr.h.
Likely related to bug #64647.
msr.h is a kernel internal header with absolutely no stable API properties.... Including it in the glibc header set would not be a good idea. (Not to mention that it includes GPL inline functions)
The reason I came across this, was becuase I was including a file /usr/include/asm/timex.h which in turn includes /usr/include/asm/msr.h. So maybe the definition of the bug should change to, "compiler bombs when including /usr/include/asm/timex.h becuase it cannot find the file /usr/include/asm/msr.h".
The purpose of the kernrel headers as I understand them are to provide the "kernel headers" for a particular release of the kernel (preferably the kernel on your system). So even if this file may have certain questioinable qualities if it is part of the kernel headers then it should be in the glibc-kernheaders.
Ehm no. The kernel headers are for the INTERNAL kernel code to compile against. The GLIBC headers (glibc-kernheaders package) describe the userspace<->kernel interface, and nothing more.
*** This bug has been marked as a duplicate of 86244 ***
<i>msr.h is a kernel internal header with absolutely no stable API properties</i> This is complete bullshit. It contains a bit of inline assembly and a bunch of #defines. Nothing in there is Linux specific, and this idiotic decision basically makes it impossible to access the TSC and other MSRs from user space. Thanks Red Hat!
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.