trying to install a module
Jonathan Hutchins
hutchins at tarcanfel.org
Sun Jun 29 14:37:06 CDT 2003
Quoting Brian Kelsay <bkelsay at comcast.net>:
> "If you run in trouble with the distribution kernel, try a vanilla kernel
> from kernel.org instead. The RH9 kernel for example doesn't work without
> some tweaks in the drivers source code because they backported lot of
> stuff from 2.5.x and broke source level compatibility with vanilla 2.4.x
> kernels.
> To me this just doesn't sound right. Is it possible that RedHat was
> trying to gain some functionality in the 2.5 kernel and that is what
> broke it for this module? I guess I don't really understand what I'm
> reading.
If you started the average modern system with a bone-stock generic kernel,
chances are a lot of the "advanced" features of a modern system wouldn't work.
RedHat, ahead of other distributions, patches in the changes and updates that
have happened since kernel release, giving you the advantages of someone who's
familiar with kernel development, someone who would know what patches and
enhancements to incorporate. They also keep an eye on new kernel features,
and where they extend functionality they patch them into the current kernel.
This is the same kind of thing that a good slackweare jockey would be doing on
his own; the only disadvantage is that RedHat by default coveres everybody,
and enables features that not everybody needs. Since a lot of the features
are implemented as loadable modules, this doesn't lead to as much kernel bloat
as it might, but it leads to some.
There are also some differences in where certain files and libraries are
stored and how things are controlled. These are features that were just not
defined anywhere when RedHat started building distributions. They made one
set of choices, other distros made different choices. Eventually, some of
these were standardised in the Linux Standard Base, but that to is a pretty
loose definitions.
If you decide to build your own kernel tree from the kernel.org source, be
aware that you may be departing from the RedHat plan in ways that could mess
up other parts of your system. This is niether RedHat's nor anybody else's
"fault" - it's just that installing a generic part rather than an OEM part may
mean that not all the flanges and bolt holes line up, you may have to do some
machining. With the generic kernel, that's understood and expected.
A couple of other things you can try are making sure that the Kernel RPM's and
the Source/Header RPMs you've installed match exactly. Probably recompilingy
our existing kernel without any changes or customisations is the best place to
start - that you know you have the correct baseline. Once you can do that,
you can proceed to customising the kernel to your system and then working in
third-party modules.
As we've seen in this list, there are some people who hold irrational
hostility to RedHat because it's big and successfull, and when you run into a
development project that has that attitude, your best bet is to change
projects, or change to a distribution they support. You can usually tell
whether they are saying "we don't have time to package RPM's, but here's a
link to someone who did" vs. "we won't even talk to those evil RedHat people,
do it our way or go away".
You can always try booting to a "plain vanilla 2.4 kernel" and see what
breaks.
---------------------------------------------------
This mail sent through tarcanfel's horde/imp system
More information about the Kclug
mailing list