Bug 3151 - Incorrect kernel headers installed for SMP
Summary: Incorrect kernel headers installed for SMP
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
: 3072 3344 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 1999-05-30 06:00 UTC by daryll
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-06-18 20:05:50 UTC

Attachments (Terms of Use)

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

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
$ grep SMP /usr/include/linux/autoconf.h

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 jturner@redhat.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 <daryll@precisioninsight.com> 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


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

Note You need to log in before you can comment on or make changes to this bug.