Kernel module permutation problems

[Matt Domsch]

On Thu, Jan 12, 2006 at 10:23:45PM +0100, Paul Wouters wrote:
> On Thu, 12 Jan 2006, Dan Williams wrote:
> 
> > 1) UP, SMP, hugemen, XEN
> > 2) i586, i686, x86_64, em64t, ppc32, ppc64, ia64
> > 3) How many past kernels to rebuild for
> >
> > Even with just these 3, we get at _least_ 30 different kernel module
> > RPMs (3 "flavors", minimum of 5 arches, 2 past kernels).  That's a huge
> > number.
> >
> > Questions:
> >
> > Is this really what we want?
> 
> I think so :(
> 
> > This is all independent of the actual specfile mechanisms and mechanics
> > of rebuilding the modules.  This is simply a question of how many
> > factors do we care about here.  It's not out of the question to start
> > small and grow the permutations out as we go along and add more
> > architectures, flavors, etc.
> 
> The way FreeS/WAN did this in the past was to build one rpm with all
> flavour kernel modules, and upon installation detect which module
> you need and link as the actual .ko file.

DKMS solves this by including driver source, and pre-compiled modules
for as many kernel/flavor/arch combinations as is desired in a single
tarball in a single RPM.  Not exactly elegant, the tarball, but
extremely effective.  Then we have just one RPM per driver version,
not one RPM per kernel version per flavor per driver version per
arch...



-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com