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.

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 :)