[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Kernel module permutation problems



Am Donnerstag, den 12.01.2006, 11:56 -0500 schrieb Dan Williams:

> So DavidZ and I were talking about this, and the matrix of different
> modules for just one SRPM here gets huge.  We have the following issues:
> 
> 1) UP, SMP, hugemen, XEN

We have no hugemem currently, but xen-guest and xen-hypervisor.

> 2) i586, i686, x86_64, em64t, ppc32, ppc64, ia64

No extras for ia64 (yet) and em64t has no special kernel/is mostly
x86_64 anyway. But you forgot ppc64iseries.

> 3) How many past kernels to rebuild for

See below:

> 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.

I count 12 kernels (without past ones) that are of interest for Fedora
Extras:

  1 | i586 -- UP 
  4 | i686 -- UP, SMP, xen-xen-guest, xen-hypervisor
  3 | x86_64 -- SMP, xen-xen-guest, xen-hypervisor (soon, hopefully)
  2 | ppc -- UP, SMP (no xen yet afaik)
  1 | ppc64 -- SMP
  1 | ppc64iseries -- SMP
===
 12 resulting RPMs build on 6 targets with one SRPM per target
^^^

> Questions:
> 
> Is this really what we want?

I don't think we get below those 12. Maybe 11 if we ignore
ppc64iseries ;-)

> How do we deal with the explosion of permutations of kernel modules?

Good question.

> Resources in the buildsystem aren't infinite, how many jobs/rpmbuilds
> should we actually kick off?

If it's only those six and no past kernel it shouldn't block the
buildsystems for too long AFAICS and IMHO.

> We can't possibly rebuild modules for every previously released kernel.[...]

Agreed. My vote: Only build for the newest one. 

<insert complains from Ralf Corsepius here>; Answer: Ralf, let's build
only for the newest one in the beginning. If that doesn't work we can
still come back to this point and discuss it anew.

> This is all independent of the actual specfile mechanisms and mechanics
> of rebuilding the modules. 

As long as we don't go back to the old scheme where one SRPM did build
one RPM.

>  This is simply a question of how many
> factors do we care about here. [...]

Did I miss anything?

CU
thl
-- 
Thorsten Leemhuis <fedora leemhuis info>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]