kernel recipes 2013 - kernel for your device

Kernel for your device

Arnaud Patardarnaud.patard@hupstream.com

# 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 <Waiman.Long@hp.com>Signed-off-by: Will Deacon <will.deacon@arm.com>Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

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