WSLIN

Project

Fri, 02 Oct 2026 15:53:49 +0800

01 自製簡易 OS - 使用C與RISC-V從零開始實作 Link to heading

為了更深入學習CS做的專案。同時支援在真實RISC-V CPU C906與QEMU上運行。
【OS】兩個Process做Context Switch實現CPU Time Slicing機制

02 Linux Driver - SPI & GPIO 驅動 Link to heading

Threads 貼文

【Linux Kernel】侵入式鏈結串列 Intrusive Linked List

Fri, 19 Jun 2026 14:57:59 +0800

一直以為Linked List是最簡單最基礎的資料結構之一，寫法就是很標準的struct裡面塞data跟指向下個節點的指標。

struct Node {
 int data; 
 struct Node *next; 
};

但這個作法有個小問題，就是直接把data的型別寫死在struct裡面，不能動態替換，如果哪天data要換型別，就要寫一個新的struct來處理，很顯然這是不太好的設計。但我也一直都認為這就是C的特性，沒有高階語言的泛型，就只能乖乖接受。

直到學習Linux後才發現，他們用了一個超聰明的方法來實現類似泛型的功能，就是把包裝的順序反過來，Node的struct裡不再包含data欄位，只留下很單純的下個節點的指標，然後將Node本身嵌入進原本data的struct裡面當作一個欄位。

struct list_head {
 struct list_head *next;
};

struct my_data {
 int data;
 struct list_head list;
};

更厲害的操作還在後面，就是當我們loop through List找到目標節點的時候，要如何才能拿到真正的data呢？Linux Kernel首先透過offsetof這個macro找出Node在data struct中的offset，再用container_of macro去把node的記憶體位址扣掉offset回推出實際data的指標，從而拿到真正的資料。

#define offsetof(type, member) ((size_t) &((type *)0)->member)
#define container_of(ptr, type, member) ((type *)( (char *)(ptr) - offsetof(type, member) ))

struct my_data instance1 = { .data = 42, .list = { .next = NULL } };

struct list_head *target_node = &instance1.list;

struct my_data *real_data = container_of(target_node, struct my_data, list);

printf("Data: %d", real_data->data);

【Observability】用Vector + VictoriaMetrics + Loki + Grafana蒐集Metrics和Logs

Sat, 02 May 2026 13:48:45 +0800

可觀測性Observability，簡稱o11y，有3大支柱: Metrics, Logs, Traces，這篇文章就來記錄我用Vector + VictoriaMetrics + Loki + Grafana蒐集Metrics和Logs的過程。

Why not Prometheus or ELK ? Link to heading

最主要的原因就是因為我的VPS只有2GB的RAM，不能跑太重量的服務。

Prometheus本身是一個時序資料庫，會定期去拉取Metrics資料後存入Db，但如果Metrics多起來就會消耗記憶體，加上他的設計是主動拉取資料，不能被動推進來，在某些場景下會不太方便，因此我決定採用更輕量的VictoriaMetrics來當作時序資料庫。

ELK(Elasticsearch + Logstash + Kibana)是一套功能非常強大的Log分析系統，但也是因為功能太強，因此占用非常大的資源(像是Elasticsearch就會對所有Log建全文索引，非常消耗硬碟空間，且因為是Java寫的因此也很占用記憶體)。

以我的需求來說不需要ELK這麼強大的功能，只需要能採集Log即可，因此選擇更輕量的Loki，他是一個資料庫，只會對Label做索引，且記憶體消耗非常低。

選好了存Metrics跟Logs的Db後，接下來就要考慮怎麼拿到系統Metrics跟Logs的問題了，一般來說我們可以用Node Exporter來取得各種硬體資訊(CPU, RAM使用率…)、Promtail取得各個Process的Logs，但這樣我們就要裝兩個東西維護上有點麻煩，而Vector就是可以一次都拿到的方案，加上他也足夠輕量，因此最後我就選他了。

【Ubuntu】Fail2Ban基本使用

Thu, 30 Apr 2026 13:48:45 +0800

我們可以先用

sudo lastb

來看一下所有失敗的登入紀錄

last

來看登入成功的紀錄

sudo grep "Accepted" /var/log/auth.log | tail -n 20

或是顯示更詳細的登入資訊

基本上只要是公開的IP，有開啟22 port就很容易看到一堆登入失敗的資訊，因此我們要來用Fail2Ban把這些掃port的機器人ban掉。

基本使用 Link to heading

安裝

sudo apt-get update
sudo apt-get install -y fail2ban

複製config檔，避免改到預設的

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

如果想設置嘗試次數、Ban多久等參數的話，可以編輯他，這邊我就先不改，用預設的即可

sudo nano /etc/fail2ban/jail.local

然後就可以啟動服務了

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

查看目前的封鎖資訊

sudo fail2ban-client status sshd

【OS】兩個Process做Context Switch實現CPU Time Slicing機制

Thu, 23 Apr 2026 13:48:45 +0800

經過了好幾個月的努力，終於成功的在RISC-V開發版上讓兩個Process 做context switch ，實現CPU time slicing 機制，雖然只是個小玩具，但絕對是學coding 這麼久以來最令人興奮的事情之一。

小小踩坑紀錄 Link to heading

同時也被一個bug困擾了快兩小時，症狀是在QEMU中都可以正常創建Process，但到了開發版上就完全沒有輸出。 Debug超久才發現是QEMU預設會幫我們清零.bss（未初始化的全域變數），而開發版則不會，導致有些變數一開始就是髒的，果然真實硬體要注意的細節還是很多啊。

【RISC-V】Sv39 - 開啟MMU實現虛擬記憶體

Thu, 23 Apr 2026 13:48:45 +0800

虛擬記憶體Virtual Memory絕對是現代OS最重要的核心機制，同時也是最複雜的系統之一，這篇文章就來記錄我對他的理解以及怎麼在OS實作。

Why Virutual Memory(VM)? Link to heading

傳統作法 Link to heading

首先我們要先了解傳統的記憶體管理像是分段Segment，有哪些缺點，以及VM如何改善的。

以分段為例，假設Process A的實體記憶體位址是0x00001000-0x00002000，Process B是0x00002000-0x00003000，可能會有以下問題:

載入時位址需Relocation Link to heading

一般編譯器編譯出來的可執行檔，記憶體位址預設都是從0x00000000開始，如果此時OS分配該Process的起始位址到0x00001000，loader就要負責處理這個Offset

擴充不易 Link to heading

如果Process A記憶體不夠用了，想要擴充，就只能申請0x00003000以後的位址使用，導致Process A內部要存取時必須處理位址不連續的狀況

權限管理不易 Link to heading

如果某個Process意外存取另一個Process的位址空間應該要觸發Exception；或是某段位址空間理論上應該要W/R only，Segement都很難做到

外部碎片化 Link to heading

當系統長時間運行後，可能不同Process間會有空閒的記憶體區塊，但卻因為太小不能放下新的連續空間的Process，導致整體看起來記憶體還夠，實際上卻放不了的狀況

Virutual Memory(VM)作法 Link to heading

VM就是為了解決以上問題出現的，他的概念就是將記憶體切分成多個統一大小的Page，一般是4096 Bytes(4kb)當作基本分配記憶體的單位，並導入邏輯/虛擬位址(Logical/Virtual Address，VA)轉實體位址(Physical Address，PA)的概念，VA就是編譯後可執行檔從0x00000000開始的位址，或是說整個Process內部實際使用的位址，PA則是真實物理記憶體的位址，也就是實際存放指令跟資料的地方。

About

Thu, 23 Apr 2026 13:48:45 +0800

Education Link to heading

國立中央大學資訊工程學系軟體工程碩士班 (預計2027畢業)
- Linux作業系統 , 嵌入式系統設計 , 無線通訊與網路 , 軟體工程
國立臺北教育大學數位科技設計學系
- 數位邏輯設計 , 電子電路 , 電腦網路 , 計算機圖學

Projects Link to heading

Skills Link to heading

Category	Technologies & Tools
Languages	C/C++ , Python , C#
System	Linux , Linux Driver , RISC-V , UART , I2C , SPI , GPIO
Tools	Git , Docker , GDB
DevOps	GitLab CI/CD , Prometheus , Grafana , Loki
AI	LangChain , Langfuse , NVIDIA MPS , YOLO , vLLM , Triton Inference Server
Application	Vue.js , FastAPI , MySQL , Unity3D

Experience Link to heading

AI Software Intern
- 研究 & 開發 AI 視覺應用技術 (模型部屬, AI Agent, GPU 資源管理, MLOps…)
遊戲程式
- 參與 4000+ DAU 手機遊戲開發與維護 (活動系統、儲值串接)

【Docker】Multi-Stage Build 減少Image大小

Tue, 21 Apr 2026 13:48:45 +0800

為了可以在CI build Docker Image時節省Image的大小，學了一下Multi-Stage build，這篇文章就來記錄一下。

Image Layer Link to heading

首先最重要的概念就是，Docker的每個Image都是由多個Layer組成的，當我們在Dockerfile裡每執行一個指令(e.g.FROM, RUN, COPY...)時，都會在原有的Layer之上再建立一個新的Layer，且該指令對檔案的任何操作或是Diff都只會記錄在這個Layer中(如果是改上一個Layer就有的檔案會複製一份再改，不影響上個Layer的完整性，Copy-on-Write)。

所以說當我們要build一個新的Image時，裡面可能就會包含很多不同的階段，像是安裝套件、編譯、打包可執行檔等等，每個步驟可能都會在對應的Layer裡產生很多最終執行檔不需要的東西，例如快取、編譯工具，導致整包Image很肥大。

FROM node:18

WORKDIR /app

# 複製 package.json 並安裝所有依賴 (包含 devDependencies)
COPY package*.json ./
RUN npm install

# 複製所有原始碼並進行編譯
COPY . .
RUN npm run build

# 啟動伺服器 (通常是 npm start)
CMD ["npm", "start"]

# 【結果】映像檔大小：可能高達 1GB+ (包含 node_modules 和原始碼)

Multi-Stage Build Link to heading

為了處理這個問題 Docker提供了多階段build的功能，我們只需要使用FROM AS就可以把每個不同階段拆開來，只傳遞該階段重要的結果(Artifact)，其他用不到的東西都可以直接丟掉。

【RISC-V】常用Register以及Caller/Callee Saved

Tue, 21 Apr 2026 13:48:45 +0800

開發OS最重要的事情之一就是要熟悉使用的指令集，但我經常忘記RISC-V有哪些暫存器以及它們的功能等等，這篇文章就來記錄一下。

分類 Link to heading

首先RISC-V每顆CPU核心都有幾類暫存器:

x0-x31: 通用暫存器，最常計算用的
f0-f31: 浮點數運算使用，xv6沒有處理這個，編譯時就擋掉浮點數運算，我暫時也先不考慮支援這個，等到哪天真的碰到計算浮點數的Exception再說
csr (Control and Status Registers): 各種控制CPU行為的暫存器，非常重要
pc (Program Counter): 下一行指令的Address

x0-x31 Link to heading

Register	ABI 名稱	Caller/Callee Saved	用途
x0	zero	—	恆為 0。寫入會被丟棄，讀取永遠得到 0。
x1	ra	Caller	返回地址 (Return Address)。執行 `call` 時自動更新。
x2	sp	Callee	堆疊指標 (Stack Pointer)。必須保持 16-byte 對齊。
x3	gp	—	全域指標 (Global Pointer)。指向靜態全域變數區。
x4	tp	—	執行緒指標 (Thread Pointer)。OS 常拿來存 CPU HartID 或 PCB。
x5 - x7	t0 - t2	Caller	臨時暫存器 (Temporary) 0 - 2。
x8	s0 / fp	Callee	Saved 0 / 幀指標 (Frame Pointer)。用於 Trace 呼叫堆疊。
x9	s1	Callee	Saved 1。
x10 - x11	a0 - a1	Caller	函式參數 0 - 1 / 回傳值。Syscall 結果也存於此。
x12 - x17	a2 - a7	Caller	函式參數 2 - 7。`a7` 通常用於傳遞 Syscall ID。
x18 - x27	s2 - s11	Callee	Saved 2 - 11。`swtch.S` 必須手動保存這組暫存器。
x28 - x31	t3 - t6	Caller	臨時暫存器 3 - 6。

註:

【RISC-V】指令、Regitster、Address長度小筆記

Tue, 21 Apr 2026 13:48:45 +0800

每次都會忘記RISC-V各種東西的長度，因此要記錄下來。

指令: 32 bits
Regitster: 64 bits
Address: 64 bits (但SV39只用了39 bits 剩下的保留)

因此如果要Load uint32到暫存器Lower的地方，就會需要lui (Load Upper Immediate) + addi指令

lui a0, 0x12345 # 載入高 20 位元，a0 = 0x12345000
addi a0, a0, 0x678 # 加上低 12 位元，a0 = 0x12345678

而如果是uint64則可以用Pseudo Instruction li

li t0, 0x1234567812345678

如果不用li就會比較麻煩，需要再加上slli (Shift Left Logical Immediate)

# 步驟 1：處理最高 32 位元的前半段 (0x12345)
lui t0, 0x12345 # t0 = 0x0000000012345000
addi t0, t0, 0x678 # t0 = 0x0000000012345678

# 步驟 2：將這段數據推到最左邊 (左移 32 位)
slli t0, t0, 32 # t0 = 0x1234567800000000

# 步驟 3：開始蓋下半層大樓 (0x12345)
# 注意：這裡通常會用另一個暫存器來湊，或者直接在 t0 上疊加
lui t1, 0x12345 # t1 = 0x0000000012345000
addi t1, t1, 0x678 # t1 = 0x0000000012345678

# 步驟 4：將兩者合體
or t0, t0, t1 # t0 = 0x1234567812345678

【OS】OpenSBI 開啟Timer Interrupt

Mon, 20 Apr 2026 13:48:45 +0800

最近在實作RISC-V OS的Trap時，剛好要做Timer Interrupt，這在QEMU中非常簡單，只要follow xv6的做法就可以實現，但在Milkv開發版上就不太一樣。

因為我的Milkv開發版上不是裸機執行OS，而是透過OpenSBI來載入並降級到S-Mode，且又因為RISC-V的Timer Interrupt 是只能在M-Mode設置，因此做起來就比較麻煩，需要在S-Mode下透過ecall 委託M-Mode的OpenSBI來完成。

xv6在QEMU上的做法 Link to heading

先來快速go through xv6是怎麼做Timer Interrupt的，首先需要先還在M-Mode時就先設置menvcfg (Machine Environment Configuration) 這個csr暫存器的bit 63來允許 S-mode 使用 stimecmp (Sstc or Supervisor-mode Timer Compare extension)。 (xv6-start.c line:59)

然後再設置mcounteren的bit 1，允許 S-mode 讀 time 計數器，沒設的話在執行

asm volatile("csrr %0, time" : "=r" (x));

時就會觸發 illegal instruction。

以上兩個都開啟後，就可以在S-Mode中設置stimecmp來開啟timer的計時功能了，時間到就會Trap，然後跳到我們寫好的Trap Handler處理。

Milkv Duo S (OpenSBI) 上的做法 Link to heading

然而因為我目前的Milkv Duo S是跑在OpenSBI下的，所以OS一進來就是S-Mode，沒辦法碰到M-Mode的暫存器，加上他的CPU C906不支援Sstc，不能直接在S-Mode設timer。

但好在OpenSBI有開啟前面兩點，並提供直接設置Timer計數的功能，因此只要ecall呼叫一下OpenSBI請他開始計數即可。

【DevOps】自架Gitlab以及Gitlab Runner跑CI/CD

Fri, 19 Dec 2025 15:00:15 +0800

Docker Compose Link to heading

services:
 gitlab:
 image: gitlab/gitlab-ce:latest
 container_name: gitlab
 restart: always
 environment:
 GITLAB_OMNIBUS_CONFIG: |
 # 讓網頁上的 Clone 連結的ip顯示正確
 external_url 'http://<區網ip>:12080'

 nginx['listen_port'] = 80
 nginx['listen_https'] = false

 # 讓網頁上的 Clone 連結的ssh port顯示正確
 gitlab_rails['gitlab_shell_ssh_port'] = 12022

 prometheus_monitoring['enable'] = false
 ports:
 - "12080:80"
 - "12443:443"
 - "12022:22" # ssh改12022，避免衝突
 volumes:
 - /path/to/your/volume/gitlab/gitlab-config:/etc/gitlab
 - /path/to/your/volume/gitlab/gitlab-logs:/var/log/gitlab
 - /path/to/your/volume/gitlab/gitlab-data:/var/opt/gitlab
 shm_size: '256m'
 networks:
 - gitlab-network

 gitlab-runner:
 image: gitlab/gitlab-runner:latest
 container_name: gitlab-runner
 restart: always
 depends_on:
 - gitlab
 volumes:
 - /path/to/your/volume/gitlab/gitlab-runner-config:/etc/gitlab-runner
 - /var/run/docker.sock:/var/run/docker.sock
 networks:
 - gitlab-network

networks:
 gitlab-network:
 driver: bridge

預設創建了root帳號，預設密碼可以用以下指令查詢

【Linux Kernel】Process and Thread的關係

Wed, 10 Dec 2025 14:57:59 +0800

前言 Link to heading

Linux Kernel中的Process, Thread其實跟我們一般認知的定義有些不太一樣，因此這篇文章來記錄這些名詞上的差異。

歷史 Link to heading

最開始的Linux，並沒有follow POSIX的標準，且當初也沒有針對多執行緒去設計架構，都還是以單執行緒為主，因此最早期設計了task_struct這個資料結構當作Scheduler調度CPU資源的單位，一個task_struct就代表一個Process。

後來的設計 Link to heading

後來多核CPU逐漸成為主流後，多執行緒的設計就很有必要了，但Linux為了方便便延續了之前的設計，將task_struct定義改為Lightweight Process(LWP)，其實就是我們一般認知的Thread的概念，而Process這個名詞則變成了一組LWP的集合，Linux稱之為Thread Group。

task_struct Link to heading

task_struct又被稱作Process descriptor(也就是OS中的PCB)，存放所有跟該LWP有關的資料，其中有兩個重要的欄位：

pid ：這個LWP的Id，所有LWP的Id都是唯一的
tgid：同一組LWP(Thread)形成的Process的Id，如果是main thread(或稱Thread Group Leader)則跟pid一致，如果是其他thread則會記錄main thread的pid

// task_struct中的欄位
pid_t pid;
pid_t tgid;

以及另外兩個重要的function：

getpid()：回傳tgid欄位
gettid()：回傳pid 欄位，也就是說pid其實實際上的意義是Thread Id，但task_struct中並沒有一個專屬的欄位紀錄tid，而是統一用pid

WSLIN

Project

01 自製簡易 OS - 使用C與RISC-V從零開始實作 Link to heading

02 Linux Driver - SPI & GPIO 驅動 Link to heading

【Linux Kernel】侵入式鏈結串列 Intrusive Linked List

【Observability】用Vector + VictoriaMetrics + Loki + Grafana蒐集Metrics和Logs

Why not Prometheus or ELK ? Link to heading

安裝 Link to heading

docker-compose.yml Link to heading

【Ubuntu】Fail2Ban基本使用

基本使用 Link to heading

【OS】兩個Process做Context Switch實現CPU Time Slicing機制

Demo Link to heading

小小踩坑紀錄 Link to heading

【RISC-V】Sv39 - 開啟MMU實現虛擬記憶體

Why Virutual Memory(VM)? Link to heading

傳統作法 Link to heading

載入時位址需Relocation Link to heading

擴充不易 Link to heading

權限管理不易 Link to heading

外部碎片化 Link to heading

Virutual Memory(VM)作法 Link to heading

About

Education Link to heading

Projects Link to heading

Skills Link to heading

Experience Link to heading

【Docker】Multi-Stage Build 減少Image大小

Image Layer Link to heading

Multi-Stage Build Link to heading

【RISC-V】常用Register以及Caller/Callee Saved

分類 Link to heading

x0-x31 Link to heading

【RISC-V】指令、Regitster、Address長度小筆記

【OS】OpenSBI 開啟Timer Interrupt

xv6在QEMU上的做法 Link to heading

Milkv Duo S (OpenSBI) 上的做法 Link to heading

【DevOps】 自架Gitlab以及Gitlab Runner跑CI/CD

Docker Compose Link to heading

【Linux Kernel】Process and Thread的關係

前言 Link to heading

歷史 Link to heading

後來的設計 Link to heading

task_struct Link to heading

【DevOps】自架Gitlab以及Gitlab Runner跑CI/CD