On 07/21/10 21:18, Somebody in the thread at some point said:
> 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
Yes the bootloader is the guy who chooses where the kernel image is to
come from and what name it'll have, and it'd be a loser on arm platforms
to make assumptions about that; it's not like just having grub in all
cases and /boot/grub/grub.conf. Unfortunately the bootloader doesn't
publish a path where it got the kernel from to the kernel itself.
The physical platform, based on what bootloader / bootloader state it
can be expected to have, is in control of where the kernel image needs
to be dropped in the filesystem, even if it's a common SoC shared with
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.
Well real devices will have special peripherals and stuff that need
specific support, I guess often it can be modularized fine but not always.
> 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.
Sounds good but I mentioned it because yum could not solve the initial
packageset if the base name for the kernel package was anything other
than "kernel". What's the plan for tagging these binary kernel packages
with SoC names in a reliable way, ie, what will those package names look
like then if they all have "kernel" basename?
Also having a relatively tiny kernel and the rest in initramfs
is an invaluable tool for ARM) helps to include as many devices and boot
styles as possible.
It makes sense from a distro POV.
IIRC there's some kconfig business where you can bind an initramfs to
the kernel image itself. If you don't take that approach, you are into
requiring the bootloader knows where the initramfs is according to the
bootloader's partition scheme and to pull it in and tell the kernel to
use it; some bootloaders might not be that configurable or capable. It
seems especially dodgy if "grubby" is going to sed the U-Boot
environment or whatever. (Even then the crazy U-Boot environment
scheme usually has a hardcoded image size given in there, eg, it only
pulls the first 2MB of a kernel and drops dead if the kernel is any bigger).