Date post: | 07-May-2015 |
Category: |
Technology |
Upload: | anne-nicolas |
View: | 476 times |
Download: | 3 times |
# 1 Thoughts about how to choose the kernel
● 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 Kernel from BSP ?
● 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 Kernel from BSP ?
● Support of chips/peripherals native in the kernel but not necessary good for the SoC support
● Get all the newest fun things
# 1 Kernel from kernel.org?
# 1 Kernel from kernel.org?● Get some extra breakages
SoC vendor can merge specific patches working for a given kernel configuration
● See cd282ef56967790aaaab89aa595f27a011091cc2 commit
# 1 Kernel from kernel.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
# 1 Kernel from distribution?● 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
# 1 Kernel from distribution?● 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
# 1 A necessary reflexion before starting
● The decision will impact the maintainance cycle and process : hard to go backward
● It often ends up likeusing BSP on non x86 platformusing distribution kernel for a x86 platform
... but no rules, depending on every specificities of the platform
# 2 Working with the kernel
# 1 Using BSP kernel
● 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
# 1 Using BSP kernel
● 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
# 1 Using BSP kernel
● 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.
# 2 Using kernel + 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
# 2 Using kernel + 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
# 3 Long term what ?
# 1 Using BSP
● 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
# 2 Using kernel + 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
# 2 Using kernel + 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
# 4 Good practice
How to make sure you will be successfull
● use patches and document them (summary / who did it / ...)Use checkpatch
● Work with upstreamsubmitting things early means more review and
comments/advices on how to solve a problem
● Do it in parallel with the support of your main kernelthe best way may be to work on upstream and
backport stuff
# 2 Using kernel + patches (distro, upstream)
lockref: use cmpxchg64 explicitly for lockless updates
The cmpxchg() function tends not to support 64-bit arguments on 32-bitarchitectures. This could be either due to use of unsigned longarguments (like on ARM) or lack of instruction support (cmpxchgq onx86). 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 thearchitecture selecting ARCH_USE_CMPXCHG_LOCKREF, move to using cmpxchg64instead of cmpxchg and allow 32-bit architectures to make use of thelockless lockref implementation.
Cc: Waiman Long <[email protected]>Signed-off-by: Will Deacon <[email protected]>Signed-off-by: Linus Torvalds <[email protected]>
How to make sure you will be successfull
● Ease your maintainance : work with upstreampatch 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
How to make sure you will be successfull
● Learn the way to communicate with upstream folks before asking question
● Put some pressure on the SoC vendor to merge their code :)