Kernel Recipes 2013 - Kernel for your device


Published on

Any industrial project based on Linux involves Longterm management of a Linux kernel and therefore a number of questions to ask about the choices to be made. BSP, Linux distribution, Which version?
These questions will be reviewed and best practices to facilitate this maintenance.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Kernel Recipes 2013 - Kernel for your device

  1. 1. Kernel for your device Arnaud Patard
  2. 2. #1Thoughtsabouthow tochoosethekernel
  3. 3. ● An ideal solution ? Good hardware support for the SoC ... ... but you need to follow the reference design ● Based on SoC + distribution ... stable but oldish environment, not supported by the distribution #1 KernelfromBSP ?
  4. 4. ● Stable but old kernel due to BSP release time ● Proprietary drivers included ● Can use quite big and specific hacks in kernel for better performance #1 KernelfromBSP ?
  5. 5. ● Support of chips/peripherals native in the kernel but not necessary good for the SoC support ● Get all the newest fun things #1
  6. 6. #1 ● Get some extra breakages SoC vendor can merge specific patches working for a given kernel configuration ● See cd282ef56967790aaaab89aa595f27a011091cc2 commit
  7. 7. #1 ● Different timelines between and distributions upstream kernel is changing too quickly (new major release ~ every 2 months) ● Linus usually says that people should use kernels from distributions
  8. 8. #1 Kernelfromdistribution? ● Some troubles with proprietary drivers Ex : emgd together with some Xorg versions ● But gains all what makes a distribution and the benefit from the kernel support of the distribution
  9. 9. #1 Kernelfromdistribution? ● May need some more work than other choices You may need some small patches with upstream or BSP but the kernel of the distribution may be quite old so missing a lot of support ● Includes some more or less experimental patches
  10. 10. #1 Anecessaryreflexionbeforestarting ● The decision will impact the maintainance cycle and process : hard to go backward ● It often ends up like using BSP on non x86 platform using distribution kernel for a x86 platform ... but no rules, depending on every specificities of the platform
  11. 11. #2Workingwiththekernel
  12. 12. #1 UsingBSPkernel ● Just add the support for your board and it’s done ! ● But you have to use the build sytem from the BSP LTIB, weird stuff mixing rpms and spec files looking like makefiles
  13. 13. #1 UsingBSPkernel ● Modifying the kernel may not be easy : how to change the configuration, how to patch ● All is hardware specific so if your platform changes, you might start again from scratch Ex : kernel for SoC S is 2.6.31 but update is done on 3.0
  14. 14. #1 UsingBSPkernel ● Uneasy to use for developing : obscure build systems may force you to rebuild everything to get your kernel ● Possibly poor documentation ● Use of abstraction layer so that the same code is used between kernel and uboot Makes it just terrible to understand : how it works / what to modify.
  15. 15. #2 Usingkernel+patches(distro,upstream) ● For security fixes (depends on the use / threat model) ● Being free to use whatever newer version of the kernel provided it fits with your needs
  16. 16. #2 Usingkernel+patches(distro,upstream) ● You have to learn how to package the kernel and make sure it integrates fine ● Some usefull tools like make deb-pkg or make rpm-pkg ● You need to know the required kernel configuration options Ex : ● Make it easy with your distribution for proprietary kernel drivers – Ex : dkms
  17. 17. #3Longtermwhat ?
  18. 18. #1 UsingBSP ● No futur ! Nearly no evolution planned ● Want to update to a newer kernel ? Back to square 1 : try to use an upstream kernel and cross your fingers ● Need to backport support/functionnalities from newer kernel ? A big pain to backport / limit to what can be backported
  19. 19. #2 Usingkernel+patches(distro,upstream) ● "Just" rebase patches. It's easy as long as changes has been properly handled Use git or make patches with things like quilt or guilt 1 patch per fix or hardware change ● You have a lot of modifications ? A lot of work but it's possible to do it as your current work doesn't depends on external vendor patchset
  20. 20. #2 Usingkernel+patches(distro,upstream) ● You can keep your good old kernel on newer distribution but distro may enable some support in libc/Xorg/... thus require newer kernels ● Some changes may introduce some forced changes on other parts
  21. 21. #4Goodpractice
  22. 22. Howtomakesureyouwillbesuccessfull ● use patches and document them (summary / who did it / ...) Use checkpatch ● Work with upstream submitting things early means more review and comments/advices on how to solve a problem ● Do it in parallel with the support of your main kernel the best way may be to work on upstream and backport stuff
  23. 23. #2 Usingkernel+patches(distro,upstream) lockref: use cmpxchg64 explicitly for lockless updates The cmpxchg() function tends not to support 64-bit arguments on 32-bit architectures. This could be either due to use of unsigned long arguments (like on ARM) or lack of instruction support (cmpxchgq on x86). However, these architectures may implement a specific cmpxchg64() function to provide 64-bit cmpxchg support instead. Since the lockref code requires a 64-bit cmpxchg and relies on the architecture selecting ARCH_USE_CMPXCHG_LOCKREF, move to using cmpxchg64 instead of cmpxchg and allow 32-bit architectures to make use of the lockless lockref implementation. Cc: Waiman Long <> Signed-off-by: Will Deacon <> Signed-off-by: Linus Torvalds <>
  24. 24. Howtomakesureyouwillbesuccessfull ● Ease your maintainance : work with upstream patch merged means it won't have to be carried forever ● Showing your code will make users, developers happy, getting them involved As a reminder: they're volunteers ● In no way, giving them some hardware will ensure they'll work on making upstream kernel work
  25. 25. Howtomakesureyouwillbesuccessfull ● Learn the way to communicate with upstream folks before asking question ● Put some pressure on the SoC vendor to merge their code :)