1OSAKA NDS Embedded Linux
Cross Forum #10
Linux Kernel のバージョンとLongterm Stable Kernel (LTS)
2020年 2月5日(水)Panasonic Corporation
加藤 慎介
kato.shinsuke@jp.panasonic.com

自己紹介
氏名

加藤 慎介 (かとう しんすけ)

所属

パナソニック株式会社
イノベーション推進部門
イノベーション戦略室

経歴

入社以来 OSの開発に従事• デジタルTVでの、独自OSからLinuxへの移行• 携帯電話のLinux移行、自社チップへのLinuxのポーティング、Linux部分の性能改善• Android製品の開発

その傍ら2002年からOSSコンプライアンス対応に従事。
社内向けのOSS対応マニュアルの作成やOSSコンプライ
アンスセミナー講師、事業部門のOSSライセンス対応のコンサルティング等を実施。OSSに限らず広く「ソフトウェア」に関する全社行政を担当。

2

目次• Kernelの取得 (Upstream Kernel)• Kernelのメンテナンス状況 (upstreamkernel maintenance)• Linux Kernel の ライフサイクル• Stable Release のルール
• Longterm Stable Kernel (LTS)• 現在のLTS
• まとめ

• 参考

3

Kernel の取得• 開発においてLinux Kernelの入手ルートは様々– Linux ディストリビューション (RedHat，Debian，Ubuntu，など) で– チップベンダーから提供を受ける (BSP：Base Support Package)– 開発部門自身で取得– ほか• では，その源流となるKernelは？
– Kernel.org でリリースされている Kernel• https://www.kernel.org/– 一般に下記などで呼称される• Upstream Kernel• CommunityのKernel• LinusがリリースしているKernel• 単に「Kernel」と言う場合も該当

4

2020/02/05
Update開発中
mainline
linux-next

Upstream Kernel

5Latest Stable

Stable とLongterm

https://www.kernel.org/ より (Screenshot : 2020/02/05)

Upstream Kernel

6

ご参考：
新しいバージョンがリリースされた直後はmainlineとLatest Stable Kernelが同じ

Latest Stable

https://www.kernel.org/ より (Screenshot : 2020/01/27)

Active Kernel releases

7

更新日がわかる(2016年以前はHP上にはなかった)

https://www.kernel.org/category/releases.html より (Screenshot： 2020/02/03)

upstream kernel maintenance (Stable and Longterm)
PrepatchPrepatch or "RC" kernels are mainline kernel pre-releases that are mostly
aimed at other kernel developers and Linux enthusiasts. They must becompiled from source and usually contain new features that must be testedbefore they can be put into a stable release. Prepatch kernels aremaintained and released by Linus Torvalds.
Mainline
Mainline tree is maintained by Linus Torvalds. It's the tree where all newfeatures are introduced and where all the exciting new development
happens. New mainline kernels are released every 2-3 months.
StableAfter each mainline kernel is released, it is considered "stable." Any bug
fixes for a stable kernel are backported from the mainline tree and applied
by a designated stable kernel maintainer. There are usually only a few
bugfix kernel releases until next mainline kernel becomes available -unless it is designated a "longterm maintenance kernel." Stable kernel
updates are released on as-needed basis, usually once a week.
Longterm
There are usually several "longterm maintenance" kernel releases provided
for the purposes of backporting bugfixes for older kernel trees. Only
important bugfixes are applied to such kernels and they don't usually seevery frequent releases, especially for older trees.
https://www.kernel.org/category/releases.html より82020/02/05
Update

Upstream Kernel

9https://www.kernel.org/ より (Screenshot : 2020/02/05)

Linux kernel の ライフサイクル
N-1

N-1.1

N

upstream kernelのバージョンアップの期
間は概ね60～70日

StableLongterm

Longterm version

N.1

N.2

N+1.1

N+2

Upstream

Upstreamに入った修正が反映される

EOL

N+1

10

N.5

EOL

N+2.1

N+3

N.4

N.3

EOL

N+3.1

N+4

最新のバージョンから「-2」のバージョンはEOLとなる
EOL

N+4.1

N+5

N+4.2

Longterm version
N+4.3

N+4.4

N+5.1

http://events.linuxfoundation.org/sites/events/files/slides/elce2015_LTSI_munakata_0.pdf より

Stable Release の ルール
It must be obviously correct and tested.

明らかに正しく、テストされているものでなければならない。

It cannot be bigger than 100 lines, with context.

文脈(変更行の前後)を含めて 100 行より大きくてはいけない。

It must fix only one thing.

ただ一個のことだけを修正しているべき。

It must fix a real bug that bothers people (not a, "This could be a
problem..." type thing).

皆を悩ませている本物のバグを修正しなければならない。("これはバグで あるかもしれないが..." のようなものではない)

It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short, somethingcritical.

ビルドエラー(CONFIG_BROKENになっているものを除く), oops, ハング、デー タ破壊、現実のセキュリティ問題、その他 "ああ、これはダメだね"という ようなものを修正しなければならない。短く言えば、重大な問題。

Serious issues as reported by a user of a distribution kernel may also
be considered if they fix a notable performance or interactivity issue.
As these fixes are not as obvious and have a higher risk of a subtle
regression they should only be submitted by a distribution kernel
maintainer and include an addendum linking to a bugzilla entry if itexists and additional information on the user-visible impact.

それらが顕著なパフォーマンスや相互の問題を修正する場合、Distribution Kernelのユーザによって報告された重要な問題も考慮するかもしれない。これらの修正が明確ではなく些細なリグレッションの高いリスクが伴うとき、それらはDistribution Kernelのメンテナによって提出され、Bugzillaのエントリがあれば追加リンクとユーザに見える影響上の追加情報を含むべきである。

New device IDs and quirks are also accepted.

新しい device ID とクオークも受け入れられる。

No "theoretical race condition" issues, unless an explanation of how
the race can be exploited is also provided.

どのように競合状態が発生するかの説明も一緒に書かれていない限
り、 "理論的には競合状態になる"ようなものは不可。

It cannot contain any "trivial" fixes in it (spelling changes, whitespacecleanups, etc).

いかなる些細な修正も含めることはできない。(スペルの修正、空白のクリー ンアップなど)

It must follow the:ref:`Documentation/process/submitting-patches.rst<submittingpatches>`rules.

:ref:`Documentation/process/submitting-patches.rst<submittingpatches>`の規則に従ったものでなければならない。

It or an equivalent fix must already exist in Linus' tree (upstream).

パッチ自体か同等の修正が Linus のツリー(upstream)に既に存在しなければならない。

11

https://www.kernel.org/doc/Documentation/process/stable-kernel-rules.rst
https://www.kernel.org/doc/Documentation/translations/ja_JP/stable_kernel_rules.txt

Longterm Stable Kernel (LTS)• 過去– Kernel 2.6.16 (2006/03/20 リリース)が初めてのLTS– その後、どのバージョンがLTSになるかのルールはなかった– 主要Distributionで採用されたバージョンが、「結果的にLTSとしてメンテナンスすることになった」というもの– 各Distributionが採用したバージョンが、それぞれLTSになっている状態に。
コミュニティとして非効率• 2011年8月：LTSメンテナーのGreg氏が、LTSの選定ルールを提案– http://www.kroah.com/log/linux/longterm-proposal-082011.html• Longterm Stable Kernel selection rules (Greg氏の提案)– a new -longterm kernel is picked every year. (毎年、ひとつのバージョンをLTSにする)– a -longterm kernel is maintained for 2 years and thendropped. (2年間メンテナンスされ、その後EOLとする)– -stable kernels keep the same schedule that they havebeen (dropping the last one after a new release happens.)
These releases are best for products that require new
hardware updates (desktop distros, community distros,fast-moving embedded distros (like Yocto)).
– the normal -stable rules apply to these -longterm kernels as
described in Documentation/stablekernelrules.txt

12upstream kernel maintenance (Stable and Longterm)

13

Screenshot： 2020/02/03

https://www.kernel.org/category/releases.html より (Screenshot： 2020/02/03)

5.4
4.19
4.14
4.9

4.4
3.16

: LTS in 2019
: LTS in 2018， Debian 10 (Buster)で使われている
Debian 10 : https://wiki.debian.org/DebianBuster: 2017年9月にGreg氏がLTSとすることをアナウンス
http://kroah.com/log/blog/2017/09/06/4-dot-14-equals-equals-this-years-lts-kernel/: 2017年1月にGreg氏がLTSとすることをアナウンス(LTS in 2017), Debian 9 (Stretch)で使われている
Debian 9 : https://wiki.debian.org/DebianStretch: LTS in 2016 (Ubuntu 16.04)
2017年9月のLinaro Connectで「6年LTS」とすることが発表された: Debian 8 で使われているupstream kernel maintenance (Stable and Longterm)

14

Screenshot： 2019/09/20

https://www.kernel.org/category/releases.html より (Screenshot： 2019/09/20)

2019年9月20日時点の情報5.4: 2019年8月にLTSとすることをアナウンス(発表時はまだリリースされていない)

Linux KernelのMLや，Greg氏のブログや，Linux関係の主要なConferenceなどで，今後のLTSについてアナウンスされることがある．

Actual Use Case of LTS
OS / ProductLTS Version
Android
Chrome Book
Windows Subsystem
for Linux 2
Raspbian (July 2019)
Amazon Linux
DebianLinux Kernel Version
3.16, 4.4, 4.9, 4.14,

15

4.19

4.4, 4,9, 4.14
4.4,4.14

4.19
4.19
3.16(8),4.14
4.9(9),4.19(10)長らくLTSとしてメンテナンスされていた 2.6.32 はDebian6のEOLとともにEOL(2016年3月)
3.2 はDebian7のEOLとともにEOL(2018年5月)
https://source.android.com/devices/architecture/kernel/releaseshttps://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices
https://devblogs.microsoft.com/commandline/announcing-wsl-2/
https://github.com/microsoft/WSL2-Linux-Kernel/
https://www.raspberrypi.org/downloads/raspbian/https://elinux.org/images/3/38/LTSI-OSSNA.pdf

upstream kernel maintenance (Stable and Longterm)

16

Screenshot： 2018/03/02

https://www.kernel.org/category/releases.html より (Screenshot： 2018/03/02)

Screenshot： 2019/09/20

その後，ここが「11-24」 に★
★

https://www.kernel.org/category/releases.html より (Screenshot： 2019/09/20)

まとめ• Longterm Stable Kernel (LTS)のメリット– ルールに従ったUpdateがなされている• Upstreamで取り込まれたバグフィックス，セキュリティフィッ
クスのみが実施される (機能等のバックポートは無い)– コミュニティによる長期のメンテナンス• 最低限2年間。メンテナーの後任がつけば延長。

• Kernelの入手経路によらず、採用時には下記でLTSのバージョンの参照を– https://www.kernel.org/category/releases.html

17具体的なチェックポイント(例)18• Linux Kernelのバージョンを聞く・確認する
その上で・・・• LTSのバージョンを使っているか？
• LTSでも最新のLTSバージョンを使っているか？

– たとえば，5.4がすでにLTSとなった現在で，「4.19 LTS」を使っているのであれば，「5.4 LTS」へ移行の予定はあるか？
それはいつか？

• マイナーバージョンのアップデートを行っているか？
– 5.4.x の「x」部分のアップデートに追随しているか？

• マイナーバージョンのアップデートの意義が分からないようだと，LTSへのパッチ(コミットログ)を見せるのも手 (これだけ修正されている，というデータとして)具体的なチェックポイント(例)19

より突っ込む場合は・・・• 今、動かしてみているLinux Kernelのバージョンを聞く (AsIsでも，動かしているのは？)• 開発環境を聞く．Yoctoだったら，バージョンは？
その上で・・・• 最新のmainlineを使っているか？
– バージョン番号だけでもダメで，upstream化しています
か？と追加質問など– upstream化していないと，結果的にベンダーロックインになる(アップデートがベンダーからのパッチのみになる)具体的なチェックポイント(例)20

こんなケースに注意！
• EOL (End Of Life) のバージョンでの提供• ベンダーの「古いバージョンでも，こちらで保証します」 (本当に出来るの？)
製品開発側での自戒？
• 製品開発で半年前にVersion決めてしまうとして，そこからの半年間でもたくさんのBugがあって，それが取り込まれている• 製品では，「バグが見つかっても踏まない状態なら，マイナーバージョンのアップデートはしなくてもよい」 となりがち• 3rdパーティー向けの(例：デバイスドライバ)サポート。「3rdバーティーのxxxはバージョンxxxだけ対応です」とかがあると，結局そこに引きずられる• そもそも，LTSの「あるバージョン」を使い続けるのではなく，LTSのメジャーバージョンも上げられる仕組み・運用にしないといけない• アップデートの条件を持っているべき．用途によって条件は変わるだろうが，条件を持って回すのがベターな状態• 本来、業界全体として取り組まなければならない話

Resources• https://www.kernel.org/• https://www.kernel.org/category/releases.ht
ml• https://www.kernel.org/doc/Documentation/process/stable-kernel-rules.rst• https://lkml.org/• http://lwn.net/• http://events.linuxfoundation.org/sites/events/files/slides/elce2015_LTSI_munakata_0.pdf– Linux Foundation主催Conferenceにおける宗像氏(ルネサス/Linux Foundation LTSIプロジェクト)のスライド• https://elinux.org/images/3/38/LTSIOSSNA.pdf– Linux Foundation主催Conferenceにおける柴田氏のス
ライド

21