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