owned this note
owned this note
Published
Linked with GitHub
# 2025-07-01 問答簡記
## 《造山者》
> [出處](https://www.facebook.com/joshu.wang1978/posts/pfbid0uTJs1aeCtbVA4FfzHpqfx2fMx1hJPG1XgjwzxSqESiZhfZrNegJ6ctcKoGvWewuDl)
1970 年代,台灣甫遭逐出聯合國、台美斷交,又逢石油危機。面對內外夾擊,一群才智出眾的年輕工程師放棄在美國的優渥前景,決意回到仍是一片荒地的新竹。他們肩負的,是在未知中開闢半導體產業的賭注。
1974 至 1976 年間,政府自工研院遴選十九人赴美國 RCA 受訓。總領隊楊丁元 (亦名楊秉禾) 兼任新澤西組領隊,成員包括謝錦銘、蔡明介、林緒德、王國肇等人,專攻設計;史欽泰率領俄亥俄組,隊員有曾繁城、劉英達、倪其良、曹興誠、陳碧灣、戴寶通、邱羅火等。彼時台灣外匯拮据,眾人每日生活費僅 18 美元,連速食店都成奢望;頭髮過長,只能以報紙挖洞互相理髮。某次週末返程稍晚,史欽泰嚴詞喝斥:「國家投注巨資,你們肩負產業興亡,豈可失職?」出國前夕,孫運璿更叮嚀:「此行只許成功,不許失敗。」楊丁元回憶此語,至今仍哽咽。
外界普遍不看好。當時台灣電子產值尚不及美國 HP 一家。直到 1980 年聯電成立並接下電子手錶大單,眾人才確信半導體可在本土扎根。台灣企業慣以「老二哲學」購買現成技術;蔣尚義直言,研發費僅需領先者三分之一,既省成本又避風險。相對地,劉德音主張,真正的競爭力在於築起自己的「根」與「活水」,即便研發昂貴,技術一旦掌握便永遠屬於自己。
台積電第一號員工曾繁城原本無意加入,多次被史欽泰游說後才赴任,終成副董事長。1990 年代初,台積電尚無品牌,員工屢遭挖角,人事主管疲於奔命。歲月流轉,史欽泰與曾繁城成為終生摯友。兩人晚年相扶於清大成功湖畔的畫面,映照出半世紀前的豪情與脆弱。
> 曾繁城先生是成功大學電機系五十五級畢業校友,曾任台積電公司總經理
> $\to$ [成大昨頒發校友傑出成就獎 台積電公司總經理曾繁城與中華電信總經理呂學錦獲表揚](https://news-secr.ncku.edu.tw/p/404-1037-47191.php),年份 19100,實為 2011 年
《造山者》聚焦的不是晶片,而是「造山」的人。影片不僅訪問企業巨擘,也追溯當年在產線作業的女工,還原竹科內軍營與靶場的記憶,讓沉默多年的基層身影得以入史。這段歷程顯示,只要世代延續那股不容失敗的決心與擔當,台灣便能在每一次危機中再生。
$\to$ 對照[奇蹟背後](https://docs.tfai.org.tw/zh-hant/film/4622)
## 探究本質
> [【畢導】太陽究竟早上近還是中午近? 99%的人都想不到!](https://youtu.be/Bl29nw5B83o)
影片首先借由《列子》中「[兩小兒辯日](https://fanti.dugushici.com/ancient_proses/70525)」的寓言提出疑問:清晨與正午的太陽大小差異是否源於距離改變。接下來的論述以視覺心理、天文計算與大氣光學為基礎,逐步說明實際原因。
影片引用[艾賓浩斯錯覺](https://zh.wikipedia.org/zh-tw/%E8%89%BE%E8%B3%93%E6%B5%A9%E6%96%AF%E9%8C%AF%E8%A6%BA)與[月亮錯覺](https://zh.wikipedia.org/zh-tw/%E6%9C%88%E7%90%83%E9%8C%AF%E8%A6%BA),指出人類在評估物體大小時會受周圍參照物影響。日出、日落時,太陽旁常有山脈、建築或樹木,相對尺度使太陽顯得更大;正午時天空單調,缺乏參照,太陽便顯得較小。這種視覺錯覺佔主要因素。
天文部分提及地球自轉與公轉在單日內造成的日地距離變化約數千公里,對比約 1.5 億公里的平均日地距離,差異微不足道;因此距離改變不足以解釋觀測到的大小差異。影片亦提醒,地球軌道為低離心率橢圓,近日點與遠日點相差僅 2% 上下,且屬年週期現象,與晨晝之間的觀感無關。
影片亦指出大氣折射在地平附近最為顯著。陽光穿過較厚的大氣層時,折射與散射令太陽近地平線時稍被壓扁並增強紅橙光,亦可能影響人對其尺寸的主觀判斷。
補充說明:
* 《列子》成書遠在孔子之後,內容多為寓言,引用其故事宜視為思考引子而非史實
* 歲差、章動與拱線進動等長週期效應確會改變節氣與近日點日期,但對單日內「清晨近、中午遠」的判斷影響可忽略
* 不同緯度因自轉線速度差異導致的距離變化並未在影片中細算;極地觀測者的實際變化更趨近於零,此屬簡化假設下的可接受近似
影片得出的結論:早晨太陽看似較大主要來自視覺錯覺與大氣折射,而非真實距離差異,其計算雖經簡化,仍足以支持此結論;若要更精細呈現,可進一步補充不同緯度與長週期天文效應對日地距離的微幅調整。
## 用客觀事實說話
> [EricccTaiwan](https://wiki.csie.ncku.edu.tw/User/EricccTaiwan)
避免說「自覺」或「自認」,評價自身就該藉由客觀事實:你貢獻哪些程式碼到 Linux 核心、你改進哪些課程教材 (當然有收錄才算)、你在課程參與中,指出哪些不足並予以改進?
避免說「投入了很大的心力去完成」,而該闡述你做了什麼,外人只能從客觀事實去衡量你。永遠為參加科技公司面試做好準備,也就是當你被問及自己在這堂課程的投入時,你要能用一系列關鍵字、實驗成果、研讀的論文、推論和實際突破來展現自己。
詳見「[Linux 核心課程自我評量](https://hackmd.io/@sysprog/linux2024-assessment)」(含錄影)
:information_source: 務必「誠實面對自己」,不要為了爭取高分而誤導自評。自我評量頁面是公開可存取的,意味著未來若你參與科技公司的面試,主管可能會參考你的自評內容。若你刻意高估自己的能力,可能導致面試官對你抱持過高期待,進而在面談中被要求深入回答大量關於 Linux 核心的技術細節,反而讓自己陷入不利。
## OSS-NA 2025 見聞
> [簡報](https://docs.google.com/presentation/d/1C-2bHarEJIXFeVRCaOM1_a0jkMhbtri4zO9JUy_tvss/edit?usp=sharing)
6/23 ~ 6/25 在黃老師的帶領下我參與了位於丹佛的 [Open Source Summit 2025](https://events.linuxfoundation.org/open-source-summit-north-america/)
以下列出我參與的活動與觀察:
#### Event Day 1 (6/23)
1. keynote
>心得:
我一直以為同樣類型的公司就是勢不兩立、恨不得幹死對方。但在這次的 keynote 讓我意識到這些國際大廠之間其實有非常非常多合作,尤其是透過開源項目,例如這次 Google 宣布將 [A2A](https://developers.googleblog.com/en/google-cloud-donates-a2a-to-linux-foundation/) 捐贈給 Linux 基金會就是個很好的例子
回去飯店後老師有跟我說明企業會將技術捐給開源基金會的考量,例如:
>1. 太成功的專案:為了避免發展方向受限於特定公司,乾脆捐給開源基金會管理
>2. 太冷門的專案:死馬當活馬醫
>3. 沒有心思投入的專案:與其花錢請工程師不如讓網友集思廣益
2. 贊助商
>心得:
我一直以為「新創」就是要發明「多了不起」的技術或是提供「多不可取代」的服務,但在活動會場我注意到大部分都公司提供的服務都只是將現有資源進行整合,例如為使用者提供統一介面、資源管理或是做安全性分析。
有些公司的核心技術甚至是開源的
3. [Harnessing Observability for 5G Performance: eBPF and OpenTelemetry Innovations](https://sched.co/1zfhy) - Fatih E. Nar & Jamie Parker, Red Hat
心得:
這場演講介紹了在使用 ebpf 時會遇到的瓶頸以及如何克服(待續)
4. 其他
> 睡前黃老爺跟我分享了一反常理的觀念:應該成為「讓別人需要」的人,而非「不可取代」的人。
> 成為「不可取代的人」看似是個合理的追求,這個選擇其實極度缺乏「成本」的概念,先不論在這過程中會錯失多少機會,最後就算真的卡了一個好位子,生命的發展也就停滯了。
> 更何況多數的例子都是失敗告終,既沒成功幹波大的,也沒留下什麼,更沒賺到錢。
「成為不可取代的人」其實是極度消極的勞工心態,思維還停留在用體力賺錢。
聰明的老闆都很努力在尋找能取代自己的人,這樣就可以去做其他事情
> 反觀「成為讓別人需要的人」看似胸無大志,但其實這才符合市場的規則
當然我還沒理解這些話的意思,但顯然我過去信奉的觀念「十年寒窗無人問 一舉成名天下知」是錯誤的,「十年生死兩茫茫,不思量,自難忘」的機會還比較大。
#### Event Day 2 (6/24)
1. Unconference session - RISC-V open discussion
>心得:我當時臉皮超厚就跑去參加 RISC-V 基金會舉辦的 open discussion
討論的前期主要是聽一群 RISC-V 在分享他們「草創」時期的奮鬥史以及各種科技公司的八卦,後期開始介紹 RISC-V 提供的免費[學習資源](https://riscv.org/community/training/),包括但不限於免費課程、免費的認證以及 Mentorship Program 等,推薦給各位
2. [Enhancing Scalability of the Vmalloc Mechanism in the Linux Kernel](https://sched.co/1zfjW) - Adrian Huang, Lenovo
心得:
3. Regression Testing Boot-time Performance in the Linux Kernel - Tim Bird, Sony
> [link](https://ossna2025.sched.com/event/1zfih/regression-testing-boot-time-performance-in-the-linux-kernel-tim-bird-sony?iframe=no)
> 心得:
4. Happy Hour by memfault
5. 其他
> 睡前黃老爺問我一個問題:「你覺得一個人的成功與否扣掉家境、人脈、長相與運氣,還有什麼因素?」
> 當然我答不出來
黃老爺:「是你對環境變化的應對能力」
#### Event Day 3 (6/25)
1. keynote
[link](https://ossna2025.sched.com/event/23B1m/keynote-ebpf-unlocking-innovation-in-the-linux-kernel-daniel-borkmann-distinguished-software-engineer-isovalent-at-cisco-and-co-creator-of-ebpf-and-cilium?iframe=no)
2. Self-Driving DAMON/S: Controlled and Automated Access-aware Efficient Systems - SeongJae Park, Meta
[link](https://ossna2025.sched.com/event/1zfmE/self-driving-damons-controlled-and-automated-access-aware-efficient-systems-seongjae-park-meta?iframe=no)
3. The Big-endian RISC-V Linux Adventure - Ben Dooks, Codethink
[link](https://ossna2025.sched.com/event/1zfn3/the-big-endian-risc-v-linux-adventure-ben-dooks-codethink?iframe=no)
4. Closing Reception
>議程結束後主辦方帶我們去[酒吧](https://meowwolf.com/visit/denver)黑皮
>活動中我認識了 PlaySation 的總工程師 [Shingo Yamade](https://www.linkedin.com/in/shingo-yamade-9a84042a/) ,他跟我介紹 Sony 的企業文化以及外國人工作的相關管道與政策。
Sony 有關嵌入式系統以及 Linux 相關的部門在東京,團隊皆以英文溝通,推薦給大家,我有他確認過即使「一句日文也不會」是否可以去 Sony 工作,他說沒問題
#### Day 4 mini summit RISC-V
## otischung
**Contributes**
[kvm-host #40](https://github.com/sysprog21/kvm-host/pull/40)
**kvm-host 原本的缺陷**
在 Host 端 arm64 架構下的 `VIRTIO_NET_IRQ` 沒有定義
**造成的原因**
Arm device tree vs. GIC 的關聯
為什麼 kvm-host 的 Arm64 移植要特別考慮 device tree (DT)?
kvm-host 一開始針對 x86-64 (即 PC-like),也就是具備 BIOS/UEFI,後者 (which) 封装的電腦周邊,不用過問記憶體佈局 (memory layout)
Arm64 在[非伺服器](https://www.arm.com/zh-TW/architecture/system-architectures/systemready-compliance-program)的狀況,多數是沒有 BIOS/UEFI 的,所以需要 DT 來描述周邊硬體,如 DRAM, interrupt, PCI, GPIO, ...
Arm SystemReady 相當於 BIOS,有了這個之後,作業系統會相對變得比較簡單,作業系統可以專心在排程、檔案系統...等任務上,不需要想我的作業系統要放在哪裡
因此,為了使 VirtIO 可以運作,我們需要檢查 VirtIO 所需要的機制是否被滿足
VirtIO Net 與 PCI 的關聯
我們需要檢查 PCI 裡面的 Memory layout 有沒有對應的 device tree 的描述,所以我們需要新增 VirtIO Net 到 interrupt map 裡面。
TODO: 提及測試方法、測試平台、預期效果
檢驗 VirtIO Net:先從確認 GIC 正常運作,再確認 VIRTIO_NET_IRQ 正常運作
如何透過 TAP 裝置連上網路?
我們需要有一套 Packet forwarding (PF) 的機制,我們希望 Guest OS 的封包可以 forward 到 Host,Host 再經由 TCP/IP stack, switch 來 forward 到其他網路上的節點。
Bridge 是 PF 的一種手段,有 bridge 的話,那麼 TAP0 與其他 Host 的網路裝置都可以用 br0 來表示
TODO: 網路連線流程
## Jordymalone
[ktcp](https://hackmd.io/@sysprog/SJYvYX_Wxl)
https://www.kernel.org/doc/html/latest/core-api/workqueue.html
絕大部分的 Linux 系統呼叫是同步 (synchronous): 收發端在所有時間維持精確同步 e.g., read/write
submit vs. complete
目前的 khttpd + CMWQ 採用何種 MT 模式?
> 根據作業要求中的設定,
> `khttpd_wq = alloc_workqueue(MODULE_NAME, 0, 0);`
> 這個方式會採用 Bound 模式,也就代表當有 HTTP 請求的工作被排入佇列時,他會被分配給提交工作當下所在 CPU 的 worker 處理。
> 做壓力測試之前看系統 kworker 的狀況
```bash
$ ps -eLo pid,comm | grep khttpd
130549 kworker/1:5-khttpd
173074 kworker/3:0-khttpd
173120 kworker/1:2-khttpd
173139 kworker/2:4-khttpd
```
:::info
這部分不清楚什麼原因導致我尚未載入核心模組前,就有殘留的 kworker
:::
如何驗證/確認該設定有效?
> 場景 1 `alloc_workqueue(MODULE_NAME, 0|WQ_SYSFS, 0);`
>
> > 這邊加上 `WQ_SYSFS` 可以讓我們透過 `/sys` 去觀察到 workqueue 相關設定
```bash
$ sudo ls -l /sys/bus/workqueue/devices/khttpd/
total 0
-rw-r--r-- 1 root root 4096 7月 6 16:28 max_active
-r--r--r-- 1 root root 4096 7月 6 16:33 per_cpu
drwxr-xr-x 2 root root 0 7月 6 16:28 power
lrwxrwxrwx 1 root root 0 7月 6 16:28 subsystem -> ../../../../bus/workqueue
-rw-r--r-- 1 root root 4096 7月 6 16:28 uevent
```
```
// 以下是 bound 相關狀態
per_cpu: 1
max_active: 256
```
:::info
* per_cpu 我認為代表這個 workqueue 是一個 Per-CPU workqueue
:::
> 使用命令: `./htstress http://localhost:8081 -t 3 -c 20 -n 20000`
> 以下節錄片段
```bash
$ ps -eLo pid,comm | grep khttpd
130150 kworker/0:9-khttpd
130549 kworker/1:5-khttpd
130679 kworker/2:16-khttpd
130686 kworker/0:17-khttpd
137754 kworker/3:5-khttpd
137783 kworker/1:0-khttpd
147161 kworker/5:1-khttpd
166881 kworker/6:2-khttpd
166948 kworker/4:0-khttpd
166958 kworker/7:0-khttpd
169602 kworker/6:1-khttpd
169668 kworker/7:2-khttpd
169739 kworker/0:0-khttpd
169744 khttpd
170321 kworker/5:0-khttpd
170341 kworker/4:3-khttpd
171799 kworker/6:0-khttpd
...
```
> 如何解讀這段資訊,以 `130150 kworker/0:9-khttpd` 為例
> 130150: pid
> kworker 即 worker thread
> `/0:9`: 0 代表這個 worker 目前在 CPU 0 上執行,9 (是編號?)
> 那要如何驗證這個 PID 為 130150 的 worker,是剛好在 CPU 0 上執行還是根據 bound 機制強制在 CPU 0 上執行?
```bash
$ taskset -pc 130150
pid 130150's current affinity list: 0
```
> 與前面的 `130150 kworker/0:9-khttpd` 前後呼應,因此可以確定 bound 屬性是有效的。
> 場景 2 `alloc_workqueue(MODULE_NAME, WQ_UNBOUND|WQ_SYSFS, 0);`
```bash
$ sudo ls /sys/bus/workqueue/devices/khttpd/
affinity_scope cpumask nice power uevent
affinity_strict max_active per_cpu subsystem
```
```
affinity_scope: default (cache)
affinity_strict: 0
cpumask: ff
max_active: 256
nice: 0
per_cpu: 0
```
> cpumask 的值為 ff (11111111),即代表他允許在多個 CPU 上執行
```
$ ps -eLo pid,comm | grep khttpd
123371 kworker/u32:2-khttpd
146130 kworker/u32:0-khttpd
150329 kworker/u32:1-khttpd
157971 kworker/u32:5-khttpd
173074 kworker/3:0-khttpd
173120 kworker/1:2-khttpd
173139 kworker/2:4-khttpd
174456 khttpd
...
```
> 關於 `123371 kworker/u32:2-khttpd` 的 u 要怎麼解釋?
> 節錄自 [How interpret kworker threads names?](https://unix.stackexchange.com/questions/152819/how-interpret-kworker-threads-names) 的說明
> The `u` designates a special CPU, the unbound cpu, meaning that the kthread is currently unbound.
```bash
$ taskset -pc 123371
pid 123371's current affinity list: 0-7
```
## alexc-313
LKMPG
struct file_operations => VFS
register_chrdev => 為何要區分 major 和 minor?
\:
> The major number tells you which driver handles which device file. The minor number is used only by the driver itself to differentiate which device it is operating on
major 是用來識別 driver,minor 用來識別 device,處理 operation 時,kernel 會用 major 找到對應的 driver,而 driver 用 minor 找到對應的 device,如果只用不區分 major 和 minor,在很多 device 跟 driver 時,會需要複雜的 mapping 方式。
THIS_MODULE 的作用?
\: THIS_MODULE 是一個巨集,展開後為 &__this_module,用來取得正在執行的模組的 struct module,裡面包含該模組的核心管理資訊
是否每個 Linux device driver 都有 device node?
\: 否
device node 的存在是基於何種考量?
\: device node 是使用者空間與核心的通訊橋樑,若是排程器這類不需與使用者互動的模組就不需要 device node
mmap 的作用? => https://man7.org/linux/man-pages/man2/mmap.2.html
\: 將檔案映射到虛擬地址空間
open+mmap vs. fopen+fwrite 變更虛擬記憶體內容,何時才會讓檔案的變更生效?
\: open+mmap: 立即,fopen+fwrite: fclose 後
如何設計實驗? => https://hackmd.io/@sysprog/linux-file-system (open file table)
stream I/O => https://hackmd.io/@sysprog/CSAPP-ch10
:
建立 process vs. 建立 thread 的成本差距? => 見課堂問答 (含錄影)
:
LKMPG: 5.4 Name Space 的作用?
\: 避免 namespace 汙染
`/proc/kallsyms` 如何從 Linux 核心和 LKM (Linux kernel module) 取得 symbol 的列表? => 見 kxo 作業描述
:
https://hackmd.io/@sysprog/linux2025-showcase => 位元運算與數值系統的應用 → 開發紀錄和錄影 (紀錄問題)
: