2026-08-01 — BPF 函式庫生態未明、Servo 0.4.0 大幅推進、Arch Linux 緊急關閉 AUR 套件領養

BPF 還沒有套件管理員：Song Liu 在 LSFMM+BPF 2026 談函式庫生態系的未來

LWN.net · 2026-07-31

在 2026 年 Linux Storage, Filesystem, Memory-Management, and BPF Summit（LSFMM+BPF，5 月 4 日至 6 日於克羅埃西亞札格雷布舉行）的一場議程中，核心 BPF 維護者 Song Liu 提出一個觀察：開發者組裝複雜 BPF 程式的方式，即將出現快速變化，而目前的 BPF 生態系完全沒有為此做好準備。他沒有帶來具體提案，而是拋出問題，讓與會的核心開發者一起思考 BPF 維護團隊是否該介入、又該如何介入。

背景：BPF 程式是怎麼組裝出來的

BPF（早期稱為 eBPF）程式目前多半以 C 搭配 libbpf 撰寫，並透過 CO-RE（Compile Once – Run Everywhere）機制，利用核心的 BTF 中繼資料，讓同一份編譯產物能跨不同核心版本執行而不必重新編譯。這套機制解決了「一次編譯、到處執行」的可攜性問題，但並沒有解決「程式碼怎麼重用」的問題——目前業界寫 BPF 程式時，大量共用邏輯是靠複製貼上，而不是像一般應用程式那樣 import 一個函式庫。

Song Liu 觀察到，隨著 Aya（Rust 撰寫 BPF 的框架）等專案成熟，越來越多開發者改用 Rust 寫 BPF 程式，而 Rust 生態系天生依賴 crates.io 上大量細粒度套件互相依賴。這與 C／libbpf 時代「單體式撰寫、少量共用」的習慣是兩種完全不同的開發模式。

核心討論：Rust 套件生態系會怎麼衝擊 BPF

Song Liu 預期會出現一個 Rust BPF 套件生態系，也就是開發者把常見的 BPF 邏輯（例如特定的追蹤、過濾、安全檢查片段）包裝成可發布、可版本化、可組合的 crate，供其他專案直接引用。問題在於，BPF 目前沒有真正的套件管理員——沒有官方管道去管理這些函式庫之間的版本相容性、核心 API 依賴、以及跨核心版本的 ABI 穩定性保證。

與會者討論了幾個潛在麻煩：

不同 crate 各自依賴不同版本的 kfunc（可從 BPF 呼叫的核心函式），版本衝突時難以除錯
BTF/CO-RE 的可攜性保證是針對單一編譯單元設計，多個獨立函式庫組合後是否仍然成立，尚無定論
驗證器（verifier）對於「拼裝」出的 BPF 程式，複雜度與可驗證性可能大幅提高

會中也提到 kfunc 的持續擴充——2026 年的討論包含是否該新增一批對應常見位元運算 compiler builtin 的 kfunc，與會者對此方向大致認同，這類擴充也被視為當初推動「快速 kfunc 呼叫」機制的原始動機之一。

影響範圍

這場討論沒有產出任何具體的維護者行動項目，Song Liu 本人也承認自己沒有明確提案。對 BPF 維護團隊而言，這是一個提早示警：如果 Rust BPF 函式庫生態系真的如預期般成長，現有以 libbpf／CO-RE 為核心的可攜性與相容性模型可能需要重新檢視，尤其是牽涉到多方函式庫組合時的驗證與 ABI 邊界問題。對於正在用 Aya 等工具寫 BPF 程式的團隊，這也意味著短期內不必期待官方會提供類似 Cargo 或 npm 那樣的正式套件治理機制，程式碼重用仍會依賴社群自發的慣例。

需要說明的是，本文主要依據 LWN 對此議程的報導撰寫；由於該場次沒有公開投影片或錄影連結，也查無對應的 lore.kernel.org 郵件討論串，因此本文以 LWN 的會議報導作為最接近的原始來源。另外，此議程實際發生於 2026 年 5 月的 LSFMM+BPF 峰會，LWN 直到 7 月底才刊出報導，兩者時間點有數月落差，屬於 LWN 常見的會議報導排程延遲。

原始來源：The future of libraries in BPF（LWN.net）、LSFMM+BPF 2026 官方議程頁

Servo 瀏覽器引擎釋出 0.4.0：單月 558 次提交，WebGPU 與版面正確性同步推進

Servo 官方部落格 · 2026-07-31

Rust 撰寫的實驗性瀏覽器引擎專案 Servo 發布 0.4.0 版 Tech Demo，對應部落格文章彙整了 2026 年 6 月份的開發進度，單月合併 558 次 commit，是繼 4 月（534 次）、5 月（391 次）後再創新高。這次更新涵蓋版面渲染正確性、WebGPU 能力、servoshell 測試瀏覽器體驗，以及一系列效能與安全性修補。

核心改動：渲染正確性與安全性

JavaScript 執行環境更新至 SpiderMonkey 140.12.0，修補了包含 CVE-2026-8388、CVE-2026-8391、CVE-2026-8974、CVE-2026-8975 在內的多個安全性問題。版面配置的核心資料結構 BoxFragment 大小從 288 bytes 縮減至 240 bytes（amd64 平台），減少約 17%，這類記憶體佈局優化直接影響大量元素頁面的渲染吞吐量。

可變字型（variable fonts）處理獲得強化，讓 Zulip、Speedtest.net 等網站的文字渲染更準確；文字裝飾線（text decoration）也修正為能跨越元素邊界連續呈現。官方表示這些改動讓 llchess.org 的相容性明顯改善，Google Photos、Cash Converters 等網站也開始正常渲染，Google Maps 與 OpenStreetMap 則是頁面可顯示但互動仍有問題。

WebGPU 與新增 DOM API

WebGPU 是讓網頁直接存取 GPU 進行繪圖與運算的瀏覽器 API，是 WebGL 的後繼者。此次新增：

GPUQueue.copyExternalImageToTexture()
GPUDevice.createQuerySet()
Command encoder 的除錯群組（debug group）方法
更符合規範的 GPUTexture 行為與 requestAdapter()

DOM 方面新增了 SharedWorker 實作、console.dir()、Document 與 ShadowRoot 上的 customElementRegistry，以及指標捕捉相關方法 setPointerCapture()、releasePointerCapture()、hasPointerCapture()，加上觸控事件處理與 textStream()。CSS 層則實驗性支援 attr() 函式、裝置尺寸／長寬比／方向／指標／懸停狀態相關的媒體查詢，以及 @font-face 中的 font-feature-settings。

影響範圍：效能與工具鏈

2D canvas 的耗電量降低 23%，版面配置流程透過 NoGC 最佳化減少逾 1% 的額外負擔，圖片解碼與快取也改為非同步處理，多個子系統減少了不必要的記憶體配置。測試用瀏覽器 servoshell 新增檔案拖放支援、頁籤列可水平捲動、全螢幕正確顯示於當前螢幕、`