or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
Select, Manage, and Backport the Long-Term Stable Kernels - 林上智 (SZ Lin), 蔡鎮宇 (Tsai, Chen-Yu)
tags:
COSCUP2021
Beginner
zh-tw
COSCUP2021
System Software
TR309
歡迎來到 https://hackmd.io/@coscup/2021 共筆
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →點擊本頁上方的 開始用 Markdown 一起寫筆記!
手機版請點選上方 按鈕展開議程列表。
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:
一些例子:
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:
這部分應該分兩種情形討論:
對上游 stable kernel 做 backport
這種時候通常會需要作者去針對 stable kernel 改寫或重新撰寫出符合舊版 API 或架構的 patch。
此 patch 的功用應該和 mainline 的 patch 相等。如果去看 4.4.x 或 4.19.x 一些 backport,不時會看到這類的情形。這也是主講內容中 stable kernel patch 提到的 option 3。
對下游或內部使用的 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:
一般常見的思維不外乎
長久下來, 難免就會累積所謂的 "技術債", 這是隱藏的研發成本.
要解這個問題, 首先要先了解公司目前的氛圍, 文化, 以及管理者在意的事情. 如果沒辦法找出共同目標, 相對上的就會難以推動.
以我的過往經驗, 這一題不是技術問題, 是溝通議題, 通常也可能參雜一些政治問題.有興趣深聊可以寄信至 szlin AT debian.org