Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 12:44:04PM +0100, Fabio Massimo Di Nitto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sven Luther wrote:
>
> |> |> 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.
>
> See Steve Langasek post with proper numbers:
> http://lists.debian.org/debian-kernel/2004/11/msg00684.html
Yeah, well, i see no significant contradiction there to what i say.
> |> 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.
>
> I did never mixed them Sven. see again the numbers and what i wrote
> in the thread. The patch generates all the required udebs. All of them
> from the kernel to the modules.
Ok. Because you can run kernels optimized differently, my misunderstanding
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.
>
> see the same post as above... i386 is one arch with 2 subarch
> and generates more udebs than arm with 5 subarch and
> yes.. i can see myself that ppc is the one with biggest amount..
> tought.. it could have been any other arch like s390 or m68k
> or ....
Exact, so what ? The problem on i386 is that you have a .udeb for different
optimizations, right ? I guess the reason why powerpc has the biggest amount
(altough powerpc uses 2.6 kernels per default, and the 2.4 ones are only there
for backward compatibility in some obscure cases, like some oldworld pmac or
obscure prep boxes), is that it is the arch which has the most chance of using
a wide variety of hardware, and thus needs the most variety of module .udebs,
the same as x86 in some way, compared to m68k or s390, where the hardware you
can use is well known, and finite in number, thus giving you a relative small
.udebs per subarch ratio (67/7 -> a bit under 10), while powerpc, with its 3
2.6 subarches has 117 .udebs, which would be around 40 per subarch.
You can't really trust 2.4 powerpc numbers, since they include apus, which is
mostly in the m68k/amiga category as far as hardware support is concerned.
Friendly,
Sven Luther
Reply to: