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

Kernel Recipes 2013 - Kernel for your device

on

  • 554 views

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, kernel.org? 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, kernel.org? Which version?
These questions will be reviewed and best practices to facilitate this maintenance.

Statistics

Views

Total Views
554
Views on SlideShare
457
Embed Views
97

Actions

Likes
1
Downloads
17
Comments
0

1 Embed 97

https://kernel-recipes.org 97

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Kernel Recipes 2013 - Kernel for your device Presentation Transcript

  • 1. Kernel for your device Arnaud Patard arnaud.patard@hupstream.com
  • 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 Kernelfromkernel.org?
  • 6. #1 Kernelfromkernel.org? ● Get some extra breakages SoC vendor can merge specific patches working for a given kernel configuration ● See cd282ef56967790aaaab89aa595f27a011091cc2 commit
  • 7. #1 Kernelfromkernel.org? ● Different timelines between kernel.org 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 : https://lkml.org/lkml/2012/7/13/369 ● 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 <Waiman.Long@hp.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  • 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 :)