Your SlideShare is downloading. ×
Kernel Recipes 2013 - Kernel for your device
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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 …

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

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Kernel for your device Arnaud Patard
  • 2. #1Thoughtsabouthow tochoosethekernel
  • 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. ● 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. ● Support of chips/peripherals native in the kernel but not necessary good for the SoC support ● Get all the newest fun things #1
  • 6. #1 ● Get some extra breakages SoC vendor can merge specific patches working for a given kernel configuration ● See cd282ef56967790aaaab89aa595f27a011091cc2 commit
  • 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. #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. #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. #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. #2Workingwiththekernel
  • 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. #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. #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. #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. #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. #3Longtermwhat ?
  • 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. #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. #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. #4Goodpractice
  • 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. #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. 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. Howtomakesureyouwillbesuccessfull ● Learn the way to communicate with upstream folks before asking question ● Put some pressure on the SoC vendor to merge their code :)