|Summary:||Incorrect kernel headers installed for SMP|
|Product:||[Retired] Red Hat Linux||Reporter:||daryll|
|Component:||kernel||Assignee:||Cristian Gafton <gafton>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||1999-06-18 20:05:50 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description daryll 1999-05-30 06:00:08 UTC
When you install an SMP kernel, the non-SMP kernel headers are installed. This makes building a stand alone device driver impossible, as the module versions don't match the kernel.
Comment 1 Jeff Johnson 1999-06-08 22:22:59 UTC
*** Bug 3344 has been marked as a duplicate of this bug. *** $ rpm -qf /usr/include/linux/autoconf.h kernel-headers-2.2.5-22 $ grep SMP /usr/include/linux/autoconf.h #undef CONFIG_SMP Since I'm running an SMP kernel on my home system, this obviously makes it more difficult to compile kernel-modules to either play with myself or for products such as 4-Front's OSS sound drivers.
Comment 2 Jeff Johnson 1999-06-08 22:23:59 UTC
*** Bug 3072 has been marked as a duplicate of this bug. *** Building Daryll Strauss' 3dfx.o device on for an SMP kernel (2.2.5-15smp) creates a 3dfx.o with the version 2.2.5-15. I had previously configured the kernel with SMP. I got the device to build with the correct version by manually editing /usr/src/linux/include/linux/version.h and adding the 'smp' postfix to UTS_RELEASE. ------- Additional Comments From email@example.com 05/26/99 13:51 ------- I have seen this discrepancy in the test lab, but have not had trouble building modules. I am forwarding this issue to a developer for further review.
Comment 3 Cristian Gafton 1999-06-18 17:35:59 UTC
The default installed headers are for uniprocessor. The defaults have to be generic, because there is no way of telling what kernel the user is running. ------- Email Received From Daryll Strauss <firstname.lastname@example.org> 06/18/99 16:02 -------
Comment 4 Cristian Gafton 1999-06-18 20:04:59 UTC
Can't you at least provide your default SMTP headers in a separate package? That way people with SMP can install it if they need it. Otherwise they only way they can get valid headers is to do a full kernel compile and install. That seems like a reasonable compromise. - |Daryll
Comment 5 Cristian Gafton 1999-06-18 20:05:59 UTC
No, because when i generate the rpm I can only have one single file for eahc header. I can not have /usr/include/linux/foo.h as two different files in two different packages. That would be solved by having different .src.rpms for the smp and non smp kernels, and there is no way I am going back to that mess. ------- Additional Comments From 06/18/99 20:58 ------- I have a .spec file that creates additional packages for the generated headers. It has some problems that should be easy for a RPM expert to fix related to the symlink for /usr/include/linux. I do not believe that it is the correct solution, but I'm willing to email it to anyone who wants a copy. Why can't you put the generated header files as part of the kernel package? /usr/include/linux/modules-<foo>/ /usr/include/linux/versions.h-<foo> /usr/include/linux/autoconf.h-<foo> And as part of either the package install or the boot procedure symlink those to the non-foo names? You want me to try and come up with a .spec file for this as well? ------- Additional Comments From 06/18/99 22:50 ------- Are you really saying "yes, it is broken, but it is too much trouble to fix?" That's not a good answer. Realize that any stand-alone kernel module that tries to use module versions is effected by this. That means PCMCIA, serial drivers, etc will all have this problem if a user attempts to build them. I'm open to any suggestion for a work around. My current solution is to tell the users to reconfigure, recompile, and reinstall their kernel, because Red Hat ships a broken kernel configuration, but I would think we could come up with something better. - |Daryll