Andy Green píše v St 21. 07. 2010 v 19:32 +0100:
On 07/21/10 19:06, Somebody in the thread at some point said:
> Adam Miller píše v St 21. 07. 2010 v 11:44 -0500:
>> I really like this idea, I think it will make widespread distribution
>> and adoption of Fedora much easier for those interested. What all
>> would need doing in terms of logistics and planning for providing this
>> sort of thing or is it really just a simple "compile different kernel
> building the kernel is only one part (and it can be solved with multiple
> kernel packages built from different configs), but the more tricky part
> is the cooperation with the booloader and boot device ...
What're you thinking about there in terms of "cooperation with the
bootloader and boot device"?
the normal sequence is kernel rpm => grubby => bootable kernel on
device, but on ARM platforms there are multiple bootloaders and they
support different device to boot from
Either the kernel is configured to use a built-in commandline which
isn't very flexible, or those configuration elements are coming from the
bootloader on a kernel commandline. If it's the latter case, it's out
of scope for a kernel package to change that.
I think we need to divide the devices first - there are developer
devices like *Plug or BeagleBoard and then there are commercial devices
like QNAP NAS etc. The commercial ones can be based on development
boards, but their configuration capabilities are limited.
A related issue I found is that the package name "kernel"
seems to be
magic. I tried making my xxx-kernel package Provides: kernel-2.6.blah,
but it wasn't enough. If it isn't fixed (possibly already, this was in
F12 time), that might get a bit messy with a bunch of
identically-named-and-arched binary packages for the different board
If I remember correctly then Debian provides one kernel per SOC and we
should do the same, have per-SOC subpackages built from one kernel
source package. If they can be integrated with the primary kernel
package, I can't tell.
Also having a relatively tiny kernel and the rest in initramfs (dracut
is an invaluable tool for ARM) helps to include as many devices and boot
styles as possible.