Select, Manage, and Backport the Long-Term Stable Kernels - 林上智 (SZ Lin), 蔡鎮宇 (Tsai, Chen-Yu)
===

###### tags: `COSCUP2021` `Beginner` `zh-tw` `COSCUP2021` `System Software` `TR309`

{%hackmd kra72OaxRTiBzdV8Y4GMKA %}

:::info
Slido: https://app.sli.do/event/ofothc1a
:::

Q&A
===

想請問RT-Linux (PREEMPT_RT)有在CIP的支援範圍嗎?
------------------------------------------
**SZ Lin** (直播最後): 有。CIP會員西門子等大公司對 Real time Linux 有需求[1]。
[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/start#kernel_maintainership

為 automotive 市場選擇 linux kernel 版本有額外的點需要考慮嗎？
------------------------------------------------------
**SZ Lin**: 可以參考 Linux Foundation Project - Automotive Grade Linux[2], 另外也要將產業標準 ISO 26262 跟 ISO 21434 納入考量. 有興趣深聊可以寄信至 szlin AT debian.org

[2] https://www.automotivelinux.org/

想請問CIP未來rootfs的搭配有沒有可能有musl libc based的呢?XD
-----------------------------------------------------
**SZ Lin**: 裡面的元件組成由 CIP 成員們來決定, 所以如果有成員提出 musl libc, 且或其他成員支持, 就會被加入至清單中.

請問kernel 那麼多商業公司再貢獻,公司利益跟開放(open source)會不會常常有衝突?? kernel社群有沒有什麼原則??
--------
wens:
1. 公司利益 (如出貨時程、工程成本、商業機密) 難免和開源有些衝突。但同時，公司的名聲 (公司利益) 也是要考量的一個因素。貢獻時，應該考慮原始碼的可重複使用性、可維護性、延續性、通用性，而不只是貢獻後就當作沒事，甚至隨意的扔出一包東西。kernel社群不會照單全收。
2. kernel社群是以kernel的發展與維護為主軸，接受貢獻時也以符合現有架構為主。若是新的功能或驅動程式無法套用現有架構，則會討論是否應該創立新的子系統或介面。新東西設計上應該以通用性為主，因此也會開放討論。

一些例子:
* Android 有些東西沒有 upstream ，因為設計架構上與一般 Linux 差異過大，且其他用途上無法受惠。
* Stateless codec 使用的 Request API 從開始討論到完全 upstream，以及後續各個 codec 使用的 userspace API 的制定，是進行了好幾年的計畫。 Request API (在我印象中) 一開始由 ChromeOS 提出，經過了很多版本的變革，主推手也換了人。H.264 stateless codec API 似乎也是由 ChromeOS 應用而來，在制定 API 的過程中，維護者希望在定案前納入不同家硬體支援，藉此了解 API 是否能滿足不同硬體設計的需求。目前仍開發中的 VP9 及 HEVC stateless codec 也這樣進行。

**SZ Lin**:
對公司來說, 開源的策略很重要, 商業公司進行開源貢獻的第一步就是區分出來核心技術跟非核心技術. 通常送進 kernel 的 patch 都不太會是核心技術 (譬如說 device driver), 又或者是要綁定特定硬體才能運行. 如果要送核心技術進去, 那背後的戰略目的也要很明確. 總結而言, 商業公司跟 kernel 社群能找到共同目標非常重要.

至於 kernel 社群的原則都寫在 "Working with the kernel development community" 文件中 [3], 不過社群運作的一些潛規則就不會明文列在上面了.

[3] https://www.kernel.org/doc/html/latest/process/

Backport 時，若 base 變化太大該怎麼處理？
----
wens:

這部分應該分兩種情形討論:

1. 對上游 stable kernel 做 backport
這種時候通常會需要作者去針對 stable kernel 改寫或重新撰寫出符合舊版 API 或架構的 patch。
此 patch 的功用應該和 mainline 的 patch 相等。如果去看 4.4.x 或 4.19.x 一些 backport，不時會看到這類的情形。這也是主講內容中 stable kernel patch 提到的 option 3。

2. 對下游或內部使用的 kernel 做 backport
這時可以考慮是否要把 API 變動相關的 patch 也一併 backport。相信這在硬體廠很常見，有些東西 upstream 了，然後再整包 backport 回到內部使用的舊版本上。如果修改幅度真的太大，導致需要 backport 的修改量過大，則可能也要考慮針對舊版去做修改了。若同時有很多這類的需求，或許也可以把進版列入考量。

**SZ Lin**:
這個處理需根據不同的情況來決定, 如 wens 所提.
隨著時間的演進, stable kernel 的 data strcuture, API, variable naming 等等內容都會跟 mainline 有越來越大的差異. 所以在 backport 時, 我以往都是緊抓著 backport 的目標, 從中找出最小修改路徑, 以滿足目標.

好奇SZ Lin您有沒有什麼「向上管理」的妙招，可以讓上司接受去contribute/upstream是為了公司好(苦笑)
----
wens:

我覺得這取決於組織本身的資源多寡以及商業模式。如果出產的都是生命週期很短的 Android 裝置，那麼可能很難推行。如果出產的是生命週期長的裝置，如網路設備，那麼 upstream 共同維護對公司產生的價值就會相對高。

以 Design House 來說，晶片設計多但生命週期短 upstream 對雙方可能都是一大疑慮。晶片廠方面在晶片產品出貨後，多數開發人力便可能轉往更新的產品線做開發；upstream 會對晶片商是否有人力繼續維護有疑慮。
不過就 SoC 來講，很多 IP Block 都有其延續性，邏輯是共通的，只是一些參數的變動。因此建議可以把共通邏輯打包成類似函式庫，再加上一兩個基準平台 (reference platform) 的特異化參數，去做 upstream 。
以網通晶片作為基準平台或許是個不錯的選擇，因為網通產品價格相對低，取得容易，且想要或願意去做修改的人也較多 (如 OpenWRT)。相較之下願意花時間去惡搞 Android 或 ChromeOS 設備的就比較少。網通晶片通常也不太會包含專利涵蓋量大的 GPU 或 Video Codec，公司方面的阻力可能也會較低。

以上是不負責任揣摩。

**SZ Lin**:
一般常見的思維不外乎
1. "RD 資源跟時間應該去做產品, 為什麼 RD 要浪費時間把修好的東西往外送"
2. "不對外揭露就是我的核心技術"

長久下來, 難免就會累積所謂的 "技術債", 這是隱藏的研發成本.
要解這個問題, 首先要先了解公司目前的氛圍, 文化, 以及管理者在意的事情. 如果沒辦法找出共同目標, 相對上的就會難以推動.

以我的過往經驗, 這一題不是技術問題, 是溝通議題, 通常也可能參雜一些政治問題.有興趣深聊可以寄信至 szlin AT debian.org