[fedora-arm] Kernels for common arm devices

[Dan Horák]

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
> >> packages"?
> >
> > 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 
> kernels.

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.


Dan