Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 11:55:06AM +0100, Fabio Massimo Di Nitto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sven Luther wrote:
>
> |
> | On these, there is a separate kernel because it is needed, not
> | because you want some random optimizations. Try to install on a
> | m68k/pmac with a m68k/amiga kernel to take one example i am
> | familiar with, and you will see whta i mean.
>
> Sven, as i wrote before, i didn't say anywhere that you must kill
> subarches and i don't understand why you keep remarking this
> bits of which i am perfectly aware of.
Because we are having a misunderstanding, see below.
> |> 20 sets of udebs, but just the common ones that can manage to
> |> boot everything since the installer will make the proper decision
> |> later.
> |
> |
> | No. This works for the -up against -smp ones, and maybe for the
> | upcoming ppc64/generic and ppc64/generic-power4, but for the rest
> | of it, they are trully separate kernel which will not run on boxes
> | they are not meant to.
>
> ok.. let's try another example:
>
> Arch foo has 20 different kind of subarches and each of them has
> 4 different flavours. For simplicity we will call them subarchN-flavM.
> where M can be:
> 0 = no optimizations of any kind.
> 1= optimization1
> 2 = ...
> 3 = ...
No, i don't believe this is the reality out there apart on x86. each arch has
a number of subarches, but not really significant amount of optimizations. The
optimization stuff is only present on x86 in a significant way, altough one
could argue that the -smp kernels are optimizations of the -up ones. I doubt
that -smp modules would play well with -up kernels though, or vice versa.
On powerpc, the sole exception to this would be the power4 optimization in the
ppc64/generic subarch, but we don't yet build this kind of kernels anyway.
> This will generate 80 kernels as a result of 20 subarch * 4 flavours.
>
> Now.. if you look at it from an installer point of view, you don't need
> 80 udebs set to boot the 20 subarches. you only need 20 udebs sets:
> subarch1-flav0
> subarch2-flav0
> .....
> subarch20-flav0
>
> due to the fact that flav0 is common to the entire subarch.
I also have some doubt that you can without risk reuse the modules of a given
subarch flavour with another flavour in most cases out there.
> This kind of "optimization" can apply to all the arch. You maintain
> the subarch (otherwise it doesn't boot). You kill the unrequired flavours.
> This reduces a lot the amount of udebs that you need.
Yes, but i don't think your reasoning applies outside of x86. At least it
doesn't on powerpc right now, so there is not much you can do.
> |> other way. This still doesn't mean that it is d-i task to
> |> workaround this kind of problems introducing extra sets of udebs
> |
> |
> | Well, how do you install on that box then, provided we can't fix
> | the above bug, if it is a bug ?
>
> You get to cooperate with upstream to get the bug fixed?
Yeah, well, not enough time for this right now, but yes, this would be the
best way. Also availability of power3 boxes to test this kind of stuff is
rather scant, and working with third party people who have sporadic access to
said hardware (because it has later to go on production, and ends up running
aix), is not optimal too.
But in principle you are right, obviously.
> | Me thinking that maybe we should use -smp variants for the power3
> | and power4 d-i kernels.
>
> That's something you don't need to discuss with me, but with
> the relevant people in the installer team.
Indeed. Or just go ahead and implement it. I doubt anyone else in the team has
had real experience qith power3 machines.
Friendly,
Sven Luther
Reply to: