[OpenAFS-devel] Linux Kernel Module build question

[Jeremy Katz]

On Thursday, July 12 2001, Derek Atkins said:
> Elliot Lee <sopwith@redhat.com> writes:
> > I gather here that your requirement here is being able to build against
> > kernel versions other than the currently running one? There has to be a
> > better way to do this than editing system files during the build, or am I
> > mistaken...
> 
> Yes, that is my requirement.  And no, currently due to bugs in
> linux/rhconfig.h, there is not (IMHO) a better way of doing it.  Take
> a look at http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=38460
> for the full explanation.  The jist is that there is no way to
> override the architecture of the currently-running kernel
> (386/586/686/athlon) because you only check #ifdef, not #if defined()
> && != 0 like you do for SMP.

But as I've stated multiple times now (and let me reiterate for good
measure), you can ensure for everything EXCEPT i386 at the moment.  The
work-around, though ugly, is to use a machine running the i386 kernel
for building everything.  But, even if you don't do that, running AFS on
anything less than a pentium-ish system is kind of silly in this day and
age (and it's not like if someone has to do this that they're not used
to having to compile things themselves...)

> > > Or you have to be very careful to only build the openafs-kernel
> > > modules for the other platforms.
> > 
> > Not at all.
> > 
> > If you look at the RH kernel RPM package, it does the right thing for each
> > possible --target that you can specify. e.g. it skips the kernel-source
> > package if you use --target=i686, but builds it if you use
> > --target={i386,alpha,ia64,otherbasearchs...}.
> 
> This is exactly what I meant.  If you're building for the base
> platform you need to build everything, and if you're building for a
> 'sub-platform' you need to be careful to ONLY build certain
> sub-packages (e.g. just the kernel modules).

This is trivial to do with the %ifarch mechanisms provided by rpm.
Again, look at the kernel package; that's what it does.
 
> > > Me, I'd just rather have one package that contained ALL the modules
> > > and just be intelligent about which one get's loaded.  Much easier for
> > > the user, IMHO.  They don't have to figure out which module-package to
> > > install.
> > 
> > Where is this intelligence supposed to be located?
> 
> Where it is currently, in the afs initscript.  It already attempts to
> choose the 'correct' module, but it only bases it on 'uname -r'.
> Obviously this doesn't help in the case of i386 v. i586 v. i686
> v. athlon.  But I've got code to fix this, and choose the module based
> upon the contents of /proc/ksyms.

Working around the system isn't the answer.  There are answers within
the system.  I've demonstrated how I have them working for me yet you
continue to come up with reasons why they don't work for you which are
mostly contrived.  If you make the system simple enough, exactly what
binary packages are provided becomes less of an issue.  Anywhere running
a significant number of machines is going to want to rebuild anyway to
include their CellServDB file, etc.  So if they're running an older
kernel, who gives a damn.  The rebuild will take care of it for them.

Jeremy