Kernel Maintainership: An Oral Tradition
Embedded Linux Conference Europe 2015 Kernel maintainership: an oral tradition – PRELIMINARY VERSION – (Image credit: Andrew Cheal under license CC BY-ND 2.0) Gregory CLEMENT Free Electrons gregory.clement@free-electrons.com free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 1/1
Gregory CLEMENT Embedded Linux engineer and trainer at Free Electrons Embedded Linux expertise Development, consulting and training Strong open-source focus Open-source contributor Contributing to kernel support for the Armada 370, 375, 38x, 39x and Armada XP ARM SoCs from Marvell. Co-maintainer of mvebu sub-architecture (SoCs from Marvell Engineering Business Unit) Living near Lyon, France Free Electrons Linux Experts free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 2/1
Motivation and Overview Motivation Implicit or unwritten rules. Make such rules more explicit. Help new maintainers and contributors. Guideline I would have liked to find. Overview The role of a maintainer Accepting a patch Interaction with other maintainers free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 3/1
The role of a maintainer Gathering patches for the subsystem Reviewing the submitted patches Through emails. Sometime through a git tree. Best case: accepted as is. Most often: ask for a new version pointing the part to improve. Worst case: rejected. Pushing the gathered patch to the upper subsystem Pull request to another maintainer. Or directly to Linus Torvalds. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 4/1
Becoming a maintainer Creating a new subsystem: Joining the current maintainer: Most obvious. Under arch/ usually a new family of a CPU or an SoC. Under driver/ usually a new framework or a specialization of an existing class driver. After being active in the subsystem especially by doing review. Generally asked by the current maintainer(s) but sometime after offering the help. Replacing a maintainer: Either co-opt by the current maintainer before leaving. Or asked by upper maintainer because of your involvement in this subsystem. Or on a volunteering base often because you need to push your own patches. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 5/1
Expectation of the submitter Reviewing the patch in a couple of days (or hours) Knowing the hardware by heart Writing and testing the code took a long time, reviewing it would be fast. Eager to have a feedback to make things move on. As maintainer of the subsystem you appear as the expert of the hardware it supports. You supposed to have all the variant of the hardware. Updating the status of the submitted patches Letting know if the patches have been received, reviewed, applied or rejected. Expected to be done in real time. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 6/1
Expectation of the upper maintainer Don’t introduce any breakage. No merge conflict. No regression. (Image credit: Mike Pennington under license CC BY-SA 2.0) free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 7/1
Timeline for the submission of a patch 1/2 At least one week between submission and being applied Let time to interested to review the series Could be shorter for a new version of a series already reviewed Stay in linux-next one week before being submitted to the upper subsystem Allow to fix merge conflicts before creating an immutable branch. Could be shorter if already been in linux-next before or if the change is well contained. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 8/1
Timeline for the submission of a patch 2/3 Deeper is the subsystem, longer will be the time between submission and merged in mainline free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 9/1
Timeline for the submission of a patch 3/3 As the Linux release candidate are weekly, then for a subsystem at N-1, series submitted after -rc6 (or rc7) won’t be in next release. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 10/1
Accepting a patch Obvious criteria No regression. Testing the hardware is nice to have but not mandatory. Must respect the coding rules (use checkpatch for this). Must compiled without warning. For a new device feature or device you can assume it was tested by the submitter. Ask for a tested by from other user if you have any doubt. Rely on testing farm if you can. Be careful of dependencies to the other subsystem. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 11/1
Organization of the subsystem git tree At least 2 branches: Could be useful to have a third branch for the release candidate after. Could have topic branches: current for gathering the fixes of the current release candidate. for-next for gathering the patches for the next release candidate. For big subsystem such as arm-soc. To let other subsystems merge your subsystem related part of series (see later). Based on the -rc1 to make the merge easier. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 12/1
The stable kernels Most of the user use kernel from a distribution. Most of the distribution use stable kernel When receiving a fix always ask if it could be useful for older kernel. Tag the commit with Cc: stable@vger.kernel.org . Even better use the tag Fixes: SHA-1 ID ("title of the patch"). free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 13/1
The linux-next kernel 1/2 The place where all are merged the commits expected to be in kernel after the next merge window closes. How to use it as a maintainer The branches merged in linux-next have to be declared to Stephen Rothwell. Send him an email with the name of the repository and the branch to merge. Do not have to be an immutable branch: all the branches are merged again for each linux-next release (on a daily basis). free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 14/1
The linux-next kernel 2/2 Benefit of being in linux-next Being merged every day with all the other branches allows detecting the merge conflict early. As a bonus Stephen often came with the resolution of the conflict. Used by the autobuilder such as 0-Day done by 01.org from Intel or the kernelci supported by Linaro. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 15/1
Dealing with your own patches You are a maintainer but you remain a developer. You have the possibility to directly applied your own patches. Not really in the spirit of an open development. Still good to have review and suggestion. However most of the time you won’t get a review as you are supposed to be the one who review! But still apply the submission process: waiting at least one week after submitting on the mailing list before applying it in your next branch. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 16/1
Coordinating with the co-maintainers 1/2 Subsystems maintained more and more often by several’s peoples. Benefits: Allow to be more responsive especially if located in distant timezone. Avoid having a stalled subsystem during holidays. Ease the turn over: easier to leave and easier to join a team. Drawbacks Need to able to find an agreement in case of opposite opinions. Need to coordinate. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 17/1
Coordinating with the co-maintainers 2/2 Each co-maintainer has her/his own interests and fields of expertise. An acked-by given by a co-maintainer is enough. Only one co-maintainer gathering the patches and taking care of the pull requests for a given kernel release cycle. Spread the review. Allow staying focused. Easier to keep the track of the submitted patches. The git repository remains shared at least for emergency. Better to decide in advance who will be the next in charge. Coordinating by email is fine most of the time. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 18/1
Coordinating with the maintainers of other subsystem 1/2 Some series modify several subsystems in the same time. Dependencies between the patches. We want that the kernel be bisectable. The order in which the patches are applied matters. Can’t predict in which order the subsystem will be merged. Need to synchronize with the maintainers of other subsystems to solve this. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 19/1
Coordinating with the maintainers of other subsystem 2/2 One maintainer takes all the series: One maintainer create an immutable branch Will have commits modifying another subsystem in her/his git tree. May cause conflict merge. A topic branch with only the patch from the series. Will be in both tree: it will avoid the merge conflict. If a fix is needed it can’t be squashed, have to be a separate commit. Merging the series in two kernel releases: No merge conflict. No immutable branch. But the feature is delayed of at least 3 months. Still possible to have the feature by delaying the clean-up in the second release. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 20/1
Submitting the gathered patches 1/2 Identify the patch to apply when reading the emails. M-x gnus-registry-set-article-mark under emacs or by using patchwork. Apply them on your branch. M-x dvc-gnus-article-apply-patch under emacs. Add your Signed-off-by (as you are going to submit them you have to do it). git commit --amend -s --no-edit free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 21/1
Submitting the gathered patches 2/2 Signed your branch git tag -s tag name branch name Push your branch on your public repository git push public repo tags/tag name Generate the pull request cover letter: git request-pull previous tag public repo \ tags/tag name cat previous tag is either the tag previously pulled during the last request or the rc1 of the current kernel. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 22/1
Final words Find the good balance between maintainer duty and submitter expectation. Be nice and helpful with the submitter especially the new ones. Remain vigilant about the code quality and stability of the kernel. free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 23/1
Questions? Gregory CLEMENT gregory.clement@free-electrons.com Slides under CC-BY-SA 3.0 e/clement-kernel-maintainership-oraltradition free electrons - Embedded Linux, kernel, drivers and Android - Development, consulting, training and support. http://free-electrons.com 24/1
Gregory CLEMENT Embedded Linux engineer and trainer at Free Electrons Embedded Linux expertise Development, consulting and training Strong open-source focus Open-source contributor Contributing to kernel support for the Armada 370, 375, 38x, 39x and Armada XP ARM SoCs from Marvell. Co-maintainer of mvebu sub-architecture (SoCs from .
Anatomy of a linux kernel development Questions : – How to work kernel code? – How to write C code on the kernel? – How to building and install the kernel on old version linux? – How to release the linux kernel? – How to fixes bugs (patch) on kernel trees? Goal : –
CARDURA ORAL TABLET: CAROSPIR ORAL SUSPENSION. cartia xt oral capsule extended release 24 hour: carvedilol oral tablet. carvedilol phosphate er oral capsule extended release 24 hour: chlorthalidone oral tablet. cholestyramine light oral packet: cholestyramine light oral powder. cholestyramine oral packet: cholestyramine oral powder. clonidine .
DIURIL ORAL SUSPENSION doxazosin mesylate oral tablet DUTOPROL ORAL TABLET EXTENDED RELEASE 24 HOUR DYRENIUM ORAL CAPSULE EDARBI ORAL TABLET EDARBYCLOR ORAL TABLET . cholestyramine oral powder clonidine hcl oral tablet clonidine transdermal patch weekly colesevelam hcl oral packet
What if Linux Kernel Panics Kexec: system call to load and boot into another kernel from the currently running kernel (4.9.74). crashkernel 128M [normal kernel cmdline] irqpoll, nosmp, reset_devices [crash kernel cmdline] --load-panic option Kdump: Linux mechanism to dump machine memory content on kernel panic.
Kernel Boot Command-Line Parameter Reference The majority of this chapter is based on the in-kernel documentation for the ichwerewrittenbythe kernel developers and released under the GPL. There are three ways to pass options to the kernel and thus control its behavior: When building the kernel.
n Linux is a modular, UNIX -like monolithic kernel. n Kernel is the heart of the OS that executes with special hardware permission (kernel mode). n "Core kernel" provides framework, data structures, support for drivers, modules, subsystems. n Architecture dependent source sub -trees live in /arch. CS591 (Spring 2001) Booting and Kernel .
kernel after the kernel rootkit has already struck. As a result, these approaches are, by design, not capable of preventing kernel rootkit execution in the first place. In the second category, Livewire [19], based on a virtual machine monitor (VMM), aims at protecting the guest OS kernel code and critical kernel data structures from being modied.
BAB 6 LEMBAGA JASA KEUANGAN DALAM PEREKONOMIAN INDONESIA KOMPETENSI INTI 3. Memahami, menerapkan, menganalisis pengetahuan faktual, konseptual, prosedural berdasarkan rasa ingin tahunya tentang ilmu pengetahuan, teknologi, seni, budaya, dan humaniora dengan wawasan kemanusiaan, kebangsaan, bakat dan minatnya untuk memecahkan masalah kenegaraan, dan peradaban terkait penyebab fenomena dan .
