[oe] Kernel Packages/Modules and Versioning

Koen Kooi k.kooi at student.utwente.nl
Thu Oct 25 12:18:57 UTC 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Graeme Gregory schreef:
> Hi, writing this with my OpenMoko hat on.

Put the kernel in the rootfs instead of in some partition :)


> Currently kernel modules create packages with names of the form
> 
> kernel-module-umaga_${PV}-${PR}.ipk
> 
> This I feel is not a good idea for mobile system that can have package
> upgrades in the field. It is my feeling that kernel modules/images
> should never upgrade without attendance from the user.

The user had to type 'ipkg upgrade' him/herself, right?

> On reason for this is to make sure user is plugged into sufficient
> power and has facilities to fix device before doing such a drastic
> upgrade.

The user had to type 'ipkg upgrade' him/herself, right?

> I would like to suggest all kernel packages are actually packaged as
> 
> kernel-module-umaga-${PV}_${RELEASE_NO}-${PV}.ipk

That is what PARALLEL_INSTALL_MODULES did and we removed that from OE.

> and that a kernel-updater is developed to guide user through kernel
> upgrades with less danger of broken devices at the end.

Your proposal would make it real easy for people to overfill their flash
by having multiple module trees in /lib/module/

> Obviously some policy would be needed so that ${RELEASE_NO}-${PV} is
> guaranteed to load on all kernel-image-${PV} kernels.
> 
> Anyway I thought I would expose this to the wider audience for more
> comments than just openmoko lists. I know this is suitable for all
> devices so Id like opinions.

We have to distinguish the case of kernel-in-rootfs and
kernel-in-own-partition before starting to discuss this.

Related: why is kernel-image packaged as kernel-image-PV_PV-PR.ipk? I
now have 5 kernel images in /boot on my a780....

regards,

Koen


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHIImxMkyGM64RGpERAozrAJ9M+aX4HPb0mxwAhhalPYA/nC5TYwCeOrvT
lUfBf0Od5UeTCF1tIdS5McU=
=+um9
-----END PGP SIGNATURE-----




More information about the Openembedded-devel mailing list