Category: Debian

Posted on
by

這是 2011/04/09 為了 GNOME 3 Launch Party 臺北場 所準備的演講。

Zeitgesit 與 GNOME 其實一年前就曾經在 blog 上介紹過。這次的演講主要是想談 GNOME 2 到 GNOME 3 開發者對於增進 UX 的典範轉移。過去十年來，GNOME 計劃雖然強調 Usability 與 Accessibilty，但始終在使用者界面中以大量的隱喻來協助使用者應用電腦系統，追隨著主流圖形化界面的影子。

直到 GNOME 3 中的 GNOME Shell 計劃，開發者開始思考當下這個世代人們在資訊系統上的困境，而對問題的重新定義，進而發展新的方向。而我試著討論除了 UX 以外，GNOME 計劃想解決的問題，重新審視人對於工作方法、記憶的使用方式。稍加提到目前 Linux Desktop / GNOME Project 可用的軟體。並再從記憶使用的觀點，進一步介紹 Zeitgeist 的想解決的問題，以及它的軟體架構與相關計劃。

簡報檔可於 SlideShare 下載。

遺失的時代精神 – Zeitgeist and GNOME Activity Journal

View more presentations from Rex Tsai

備註: 遺失的時代精神是因爲 Zeitgeist 與 GNOME Activity Journal 要在 GNOME 3.2 纔會納入 GNOME Project.

Posted on
by

簡介

自從 Wine 1.0 在 2008 年六月釋出之後，便開始以兩、三周為週期，開始固定的釋出新版。Wine 是針對 POSIX 相容的作業系統所設計，目前 Wine 已經被移植許多平臺上，除了 Linux 外，也可以在 Solaris, FreeBSD, x86 版本的 Mac OS 上使用。經過長期的開發與社羣支援，目前在 Appdb 中已有超過一萬六千個軟體測試報告，其中有將近 3000 筆是屬於高度可用 (Platinum List) 的軟體。

在 Appdb 中仍有大量的軟體存在執行的問題，造成使用困擾，甚至無法使用。這與 Wine 的設計有關，Wine 跟 Dosbox, zsnes 不同，既不是模擬器，也不是虛擬機器。它是以軟體方式模擬出 Windows® 作業系統所需的軟體架構 (Software Stack)，理論上只新增一層 software layer 會比虛擬化成本低廉。

雖然 Wine 計劃經過十幾年發展，但是市面上目前為止沒有任何書籍介紹 Wine 及其程式架構，開發者只能參考少數幾份線上文件與 Wiki 來理解 Wine 的程式架構。本文稍加介紹 Wine 的相關設計。

軟體架構與初始化簡介

根據 Wine Developer’s Guide，軟體架構如下

要在 UNIX 中模擬一個 Windows® 作業系統，有許多差異需要克服，且 Wine 為了開源授權的合法性，並不對 Windows® 本身進行反組譯，而是用黑箱測試法所開發出來，並參照開發文件逐步實做所有的 Win32 APIs。問題在與 Win32 API 文件並沒有完全開放，不同版本作業系統間，也有些微行為上的差異。然而 Windows® 有著為數不少缺乏文件的 APIs. 甚至錯誤的 API 反應等等，Wine 都需要一一的實踐。加上仍有一些未開放的低階 API，以及一些缺乏文件的協定或設計，Wine 計劃可以說是以血淚走過來的開發工作。

以 Wine 模擬 Windows® 最重要的功能之一就是 Wine server, 它基本上是提供作業系統核心模擬的功能，負責 Inter-Process Communication (IPC), synchronization 與 process/thread management 等等工作。Wine server 是一個獨立的程序，每次啟動任何 Windows 程式前，它會優先被叫起。若出現了什麼問題，也要確保砍掉 (kill) 它後，才能乾淨的重新執行。

而在 Wine preloader 載入 .COM / NE / DLL / PE 前，由於每個程序都將使用自己的記憶體空間，Wine 要先依照不同的執行檔格式需求建立 Memory layout，為了能夠在 Linux 中製造出跟 Win32 一樣的記憶體位置，除了試圖將相關的 DLLs 載到正確的記憶體位置 。Wine 也要避免 dynamic linker 預先把 Wine 所需的函式庫配置 (mapping) 到錯誤的位址，於是修改預設的 ELF 初始化程序，以 syscall 將相關的函式庫配置到正確的位置。

另外在 Windows® 中，每個 process 或 thread 有一塊資料結構稱做 Environment Block (PEB – Process Environment block or TEB – Thread Environment Block)，這些資料中包含了 TLS slots, message queue, error code (SEH, Structured Exception Handling) 等等，這塊資料結構提供了 Windowing, Threading 以及錯誤處理等所需資訊。在建立 PEB/TEB 後，才初始化 process heap，載入執行檔，依照執行檔指示建立 stack，最後才將控制權交給執行檔的 EntryPoint。

上述工作均由 NTDLL/KERNEL32 處置，NTDLL/KERNEL32 也會負責傳遞執行序資訊給 Wine Server. 至於啟動後的 Graphics Device Interface 與 X11 的圖形界面轉換由 GDI32 處理。 USER32 則實做 Windowing and Messaging subsystem. 像是一些狀態列顯示等功能，都已經實做完成。

例外一個值得一提的是錯誤處理的機制，在 Windows 上 exception handling 的方式比 Linux 中複雜許多。以 STATUS_ACCESS_VIOLATION / Segmentation fault 為例子，在 Linux 中只是吐一個 SIGSEGV 錯誤，在 Windows 中則會吐出一個 Exception，還會帶上錯誤位址 (faulting address) 等資訊，也可在 SEH 中指定 handler function 來處理錯誤事件。在 Linux 中，並沒有所謂的 system exception interface，Wine 為了模擬出 Windows 的錯誤處理機制，是將 exception 轉為 signal 來模擬。

除了上述幾個主要的核心程式外，Wine 也實做了許多軟體原件，像是 Cryptography, DirectShow Framework, Direct3D shader -> GL mapper, Network protocol stacks, DirectSound (ALSA, OSS), DirectInput, DirectShow, DirectDraw, Direct3D 等等。甚至連 MSHTML / IE 都已經以 Gecko Engine 實做。

目前 Wine 在編譯時 已經支援 64 bits 也支援 WoW64 來跑 32 bits 程式。

開發模式

Wine 是用 git 管理，任何人都可以隨意 commit patches, test cases 到 patches mailing list 上，經過公開的 code review 後就會再下一次 release 中被合併。如果有任何技術上的疑問，則會被提到開發論壇進行討論，有歧異或暫時無法解決的問題，會被彙整到問題追蹤系統中，是相當透明開放、平等的開發模式。

由於 Wine 是完全重製 Win32 APIs, 且是黑箱測試開發模式，難免會出現修東壞西的悲慘現象。為了避免舊問題在新版中重現，Wine 設計了一套測試方法，來作 Regression Testing，藉此確保軟體品質。不過這個方法只能測試功能性的問題，難免還是避免不了一些圖形界面的變異。

Wine 計劃授權原本是採用 MIT，但在市場高度期待，出現了數家不同的公司為不同的平臺提供服務，社羣為了避免多家營利公司商業競爭造成開發資源分散，2002 三月後已經改成 LGPL.

也由於授權開放，Wine 的開發成果如 D3D 也被整合到 VirtualBox 中。另外像是想重新實做開源Windows® XP/2003 的 ReactOS 計劃，其軟體層也使用 Wine Libraries。一般開發者也可以用 Winelib 作為跨平臺的函式庫，在 Linux 上將程式移植到 Win32 平臺上。 (類似 mingw)

目前在 Linux 上，Wine 對於音效支援，只有 OSS 與 ALSA。社羣已有 PulseAudio，但由於開發團隊策略上的考量，希望朝向支援 OpenAL 的方向，因此尚未被整合到官方版本。至於在 MacOS 上，其圖形界面驅動程式還是 winex11.drv ，需要使用 X Server 才能使用，OS X 上 的 Quartz 在 2010 時曾經有一部分實做，但已停止開發，功能也暫時無法使用。

使用現況

目前 Wine 計劃處在一個尷尬的狀態。Wine 已經完成很大部分的 Win32 Libraries. 但仍有尚未實做的部分，為了能夠順利使用，使用者仍必須使用 Microsoft  函式庫 (以下稱為 native)。又因為已高度實做 Wine 的函式庫 (以下稱為 build-in)往往有不相容 native 函式庫的問題。也因此使用者現階段而言並不容易只使用一套 Wine 設定來套用所有的 Win32 應用程式。

結局就是造成使用 Wine 執行 Win32 程式時，常需要搭配不同的函式庫。例如這一版本需要 native 的 yyy.dll 配合 build-in 的 zzz.dll，另外一套軟體卻可以只用 build-in dll 執行。

如果軟體出現相容性問題，不再像初期一樣，只要靠換 Win32 Libraries 就可以排除，因為每個原生函式庫有高度相依性。由於安裝軟體時，常常需要用到一些 Microsoft 的程式碼，或者偶爾也許要微調一下 Windows Registry Keys 才能順利安裝。因此常需要透過特定到程序才能成功安裝，因此網路上有許多第三方工具。最常用也最知名的就是 Winetricks.

雖然 Wine 已經開始有些像是 Picasa, TeamViewer 等等的商用軟體應用，以 Wine 直接提供原生 Win32 程式給 Linux 平臺。但他們的做法，都是隨贈一套已調整完成的 Wine 系統。

由於 Wine 執行環境可以安裝在不同的 sandbox，因此系統中可以有多套不同的 Wine 同時執行。這種技巧叫做 bottle. 使用者可以透過不同的環境變數，來設定 Wine 所要使用的設定檔路徑，載入 Win32 程式時，也會啟動不同的 wine server，不同的 bottle 會是獨立的執行環境，可作不同設定或安裝不同版本的函式庫。

使用者可以透過環境變數或第三方工具，來測試配置各種不同的軟體，在 Linux 上可以使用今年剛發表的 wibom。在 MacOS 平臺上，由於編譯的困難性，可以使用 Wineskin 之類的工具來協助安裝管理 Win32 系統。此外，像是 Crossover, Bordeaux 等公司也提供商業版的友善界面與預先調整好的安裝工具等服務。

在 Appdb 上已經有眾多程式資料，何不試試能否在 Linux 執行看看你最喜歡的 Windows 程式呢? 🙂

Posted on
by

開源工具現狀

許多開發者都有介入中大型專案的經驗，常必須試圖理解原始程式的設計，或多或少都有在程式碼迷宮中找路的經驗。有些專案，程式碼結構嚴謹，軟體設計應用 Design Patterns. 見名稱、參數即可推斷程式結構，閱讀如沐春風。

但若碰到未經重構的成年老專案，程式邏輯因為年久失修，塞滿各個開發階段的臨時解決方案，常常已經複雜到難以一眼望穿理解。若是像記憶力虛弱如我，常常追了後面幾千行、跳了三個檔，就忘了前面幾個檔案的函式名稱。於是常常輔助紙本畫流程圖，但是手繪圖往往不敵跳來繞去的程式碼邏輯。還是得靠程式碼解析視覺化工具來協助理解。

繪製 Call Graph 的工具非常多，一般可以分作 Dynamic analysis 與 Static analysis 兩種做法。在臺灣，最知名的商業版本工具，大概是 Source Insight。不過我不用 Windows，對於缺乏原始碼的開發工具興趣也不大。

開源的 Dynamic analysis 有像是 Jserv 介紹過的 CodeViz 或是 ncc。不過這類工具需要 patch gcc，不特別適合嵌入式系統專案。因爲原始碼常常只支援特定平臺，或是無法取得編譯工具原始碼，此外不同版本的 compiler 偶爾會造成不同的問題，造成使用上的困難。

一種比較乾淨的做法是像 KCachegrind 利用 valgrind 來收集資料，或 Gprof2Dot 利用 gprof 的輸出資料。再者是利用 gcc 的除錯功能，把 internal representation (RTL) 倒出來，再用egypt 或 Python-RTL 來判讀或繪圖。

至於 Static analysis 有Fred Chien 介紹過的 cflow 或是 Doxygen 也有類似的繪圖功能。也有工具是配合 cscope 或 global，例如有人幫 CScope 刻過圖形界面，Vim 有個 CCTree 可用。

CallGraphviz

以上這些工具各有優缺點。

最常見的問題是許多工具無法處理 function pointer / dynamic dispatch，最終還是要人力介入。另外一個使用上的困擾是，這些程式會一口氣畫出整個程式碼的結構圖。

太多資訊其實妨礙理解，因爲用途常常只是追一個臭蟲，程式開發者只想畫出特定路徑來釐清問題。而context-sensitive 的 call graph 測試工具又耗費資源。

若用 CodeLite, Code Blocks , Eclipse CDT 等開發工具，工具已經內建或整合 cscope /global，提供 symbol lookup 功能，於是開發者很容易用滑鼠查閱函式定義或實做，或也可以搭配 LXR 來瀏覽程式碼。已經不需要像是 cbrowser 專屬的程式碼瀏覽工具。

所以需要的是可以手動的將目前程式情境視覺化的工具，網路上已經有其他開發者做了 Bash: C Call Trees and Graphs 或是 Global-calltree。或是像 ypwang 的方法，記錄函式進出點，再手動繪圖。

這些工具大多是整合 shell scripts，操作上有點不便。另外我也不喜歡 Call Tree 的圖式，因爲樹狀圖無法表現遞迴或交互關係。

於是查找一下，決定拿 cscope 加上 Graphviz 的 DOT 語法來用，改了一個 CallGraphviz。它的功能是一個 Graphviz 前端，後端還是使用 cscope 查 symbols，為了可以即時瀏覽就拿了 xdot 當作界面。xdot 是以 PyGtk 開發，非常容易更改，不到三百行就加入我需要的功能。
 

使用方法

  • python visualizer.py
  • 按下 “New”, 選擇要分析 C/C++ 專案目錄。
  • 於 “Search symbol” 鍵入要追蹤的函式名稱。
  • 每次鍵入新名稱，他會自動對應圖中已輸入函式是否爲 caller or callee，並自動畫圖。

CallGraphviz 可以將繪圖結果存成 dot 格式檔案，然後再利用 dot 指令轉換格式。不過它只是把曾經查過的名稱記錄起來，開啟時重新查 cscope 而已，若圖大時，每次開啟可能會十分緩慢。

原始碼可於 github 下載，授權採用 GNU Lesser General Public License.

延伸閱讀
Python Call Graph

Posted on
by

Firefox 4.0 出來之後，一直沒有抽時間出來更新 CertAlert，不過最近看到 AT&T 上的 Facebook 流量莫名被轉到中國跟南韓去，似乎有某種暗黑勢力蠢蠢欲動。

頗擔心 CNNIC 有惡意作為，稍微更新了 CertAlert，讓它支援 Gecko 2.0 XPCOM API，可以裝在 Firefox 4.0 上。新版安裝檔可以於 github 下載。

Mozilla 官方 AMO 因爲疏於更新，暫時被拿下來了，將重新上傳等官方審閱後即可再次下載。

2011-03-29 01:30

官方 AMO 已經重新開放安裝，仍於申請審閱程序中。

Posted on
by

「利益揭露: 本文英文書籍連接使用 Amazon Associates Program.」

我相信絕大部分 Linux 開發者都會告訴你，Driver 的開發比 Linux Application 容易許多，即便寫驅動程式聽起來莫名偉大，其實也不過是一段 C/assembly 的組合程式碼。有別於桌面應用程式，Linux kernel API 較少因爲不同的新軟硬體規格，而進行大幅度 API 更動 (參數的簡化倒是十分常見)，且由傑出的軟體開發者撰寫的核心架構，穩定性已經十分可靠。

相較與 userland 高度複雜的設定機制，Linux Kernel 暴露的界面十分簡單，在硬體穩定的前提之下，你也難得碰到 API 反應與預期不符合的處境。一般開發者對於核心驅動程式上手的時間，應該不會比開發桌面軟體來的更久。花費時間較多應該是研讀硬體手冊，以及不嚴謹的開發習慣造成臭蟲而所需的除錯時間。

對於深具經驗的開發者，在學習開發 Linux kernel driver 時，最快的方法莫過於直接解開 Kernel tarball, 切進欲開發的 subsystem 目錄，拿出 global, vim, LXR 直接把現成程式碼當作範例學習，很快就可以理解程式結構。不過，偶爾還是需要參考書來驗證對於架構得理解是否正確，另外接觸新的 subsystem 時先閱讀入門文章也可以減少無謂的撞牆期。

所幸，幾位 Linux kernel hacker 也是傑出的文件作者。在 Linux kernel sourc tree 中已有一些各子系統的架構、操作參考文件，涵蓋了基本的 coding style、設計哲學等。另外，像是 Robert Love, Greg Kroah-Hartman (PCI, USB maintainer) 等開發者也出版了完整的書籍，很值得參考。

不過市面上針對 Linux kernel 開發的書籍也不少，那一本是適合你的呢？這類的技術書籍，通常設定不同的讀者羣來設定內容，有的偏重知識，有的偏重操作實務。且出版版次也會影響所介紹的 API 差異，造成無法編譯其範例，但並非舊書，所談之理論就不正確。

以下分享不才對於市面上 2005 年之後出版的核心開發書籍的評論，希望對於想擴充團隊圖書館的朋友提供些參考。

Linux Kernel in a Nutshell 是 2006 年年底發行，作者是 GregKH，使用核心為 2.6.18，部分操作方式或指令已經略有更改。GregKH 基於讓更多新手參與開發行列，針對的讀者是從未編譯過 Linux kernel，想瞭解下載、設定、編譯需求等等細節，適合剛從其他平臺進入 Linux 核心開發的朋友，可以較快熟悉核心編譯的操作程序。書內主要介紹通用性知識，因此未提各 distro 間安裝 kernel 的細節 (如 initrd 建制方式)。

LKN 已採 CC BY-SA 2.5 授權。電子書可於 GregKH 的網頁下載。

Understanding the Linux Kernel, Third Edition 這本由兩位博士 Daniel P. Bovet 與 Marco Cesati 所撰寫，從 2000 年底出版之後，到 2005 已經是第三版，介紹的核心是 2.6.11。有中譯版。

此書結構以流水帳方式帶過各個子系統，但稍嫌膚淺的僅僅介紹表面的細節，未能給予概觀性的理論說明，也未能直指程式核心。篇幅常用於註記資料結構或函式用途，適合想尋著麵包屑理解 Linux kernel 運作的探險家使用。

Professional Linux Kernel Architecture 在2008 年出版，作者是 Wolfgang Mauerer，作者的背景是量子物理學家。在沒有社群內知名開發者的背書與協助下，他完成了一本巨大的書籍，篇幅高達 1368 頁。

有別於 UTLK，也許是為了非科班出生的讀者，作者試著詳盡的敘述作業系統的基本概念，另外一方面也以程式碼告訴讀者 Linux 的運作模式。

如果你讀不下純粹理論導向的作業系統教科書，而想透過 Linux理解一個作業系統的設計原理，這是適合你的書。本書基於 Linux kernel 2.6.24.

身為知名的 kernal hacker, Robert Love 在 Linux Kernel Development (3rd Edition) 一書中為讀者拆解 Linux kernel source tree, 直接從設計理念切入，酌以程式碼輔助，讀者需要有作業系統理論素養以及 Linux 開發經驗，才能消化理解筆者的解剖。最新第三版發表於 2010 年初版，更新到 2.6.34.

簡體中譯版 Linux 内核设计与实现 翻譯自 Linux Kernel Development 第二版。正體中文版有維科圖書有限公司出版沈中庸, 沈彥男翻譯的 Linux 核心開發指南, 2/e。

Linux Network Internals 的作者是 Christian Benvenuti，發表於 2005 年。少數專談 Linux Network stacks 的書籍，作者循序的從設定工具、核心啟動開始，逐一介紹 封包傳送接受、Bridging、IPv4、Neighboring Subsystem 與 Routing。本書基於 2.6.12.

書中涵蓋了 Layer 2, Layer 3 等協定, 可惜遺漏了 IPv6, IGMP, PIM, Traffic Control, Netfilter, Virtual devices (802.1Q, bonding, IPIP, GRE) 等等重要原件。讀者需要基本開發能力與網路協定常識。此書有中譯版。

The Linux TCP/IP Stack: Networking for Embedded Systems 第一版發表與 2004 年，最新第二版 2006 年，針對的版本是 2.6.16，作者是 Thomas F. Herbert。此書對於讀者的定位不明。雖然意圖以一個章節討論嵌入式系統中的 TCP/IP Stack，但除了說明一般嵌入式系統需求外，缺乏實際有用資訊。

書籍想涵蓋各種 TCP/IP Stack 所涵蓋的項目，但章節設計雜亂，從基本的 Network Stack 開始介紹，對於 API 部分又缺乏系統性描述。既無法瞭解網路協定，或撰寫網路程式或作業系統核心架構。

書中時常夾雜敘述與程式碼，令讀者難以連貫消化，讀者需要開啟原始程式碼才能領會作者的。這是一本關於網路協定的原始碼註記，適合已具核心開發經驗的開發者參考使用，考量其版本日期，書籍的功能可能比自行追蹤程式碼的效用還差。另外，若你想瞭解嵌入式系統，這也不是你該買的書。

Linux Device Drivers, 3rd Edition 的作者是 Jonathan Corbet (LWN 的創辦人)、Alessandro Rubini、Greg Kroah-Hartman。即便 LDD3 已經出版許久，還是所有想寫 Linux kernel driver 的第一優先入門參考書阿。此書有中譯版。

LDD3 務實的從實做範例開始，帶領讀者理解各種 subsystem，含括了入門操作與基本觀念，對於初次開發 lkm 的開發者提供了燈塔般的指引。

LDD3 授權採 CC BY-SA 2.0，線上版可於此下載 http://lwn.net/Kernel/LDD3/。但由於書籍年代較久，針對的核心版本為 2.6.10，書中範例需要一點調整才能正常運作。已有同好改了幾份擺在  github (jesstess, martinezjavier).

Essential Linux Device Drivers 的作者是長期在 IBM 工作的 Sreekrishnan Venkateswaran，參與 Linux Watch, PDA, Nurse Call Systems, Merlin Patient Care System 等等開發專案。有正體中譯版 Linux驅動程式開發實戰 以及簡體中譯版 精通Linux驅動程序開發。

這本書是作者的實務工程筆記，出版於 2008 年，針對核心為 2.6.23/2.6.24，透過此書新手可以從中漫遊一個深具經驗的開發者，如何從原始碼迷霧之中理解 Linux device  driver，老手或可從雜亂的描述中再次驗證自己的理解。

雖然篇幅高達 744 頁，卻被引用程式碼佔了許多頁面。這本書不足以提供開發者撰寫驅動程式的基本觀念，也無法協助理解作業系統概觀。

作者另有一小冊 Debugging Linux Systems 電子書短短九十頁，帶過幾個常見的核心除錯工具與技巧，很有實務參考價值。

《The Linux(R) Kernel Primer: A Top-Down Approach for x86 and PowerPC Architectures》 出版於 2005 年，作者是 Claudia Salzberg Rodriguez, Gordon Fischer, Steven Smolski。有中文版，但評價頗差。

書名讓人非常期待總算有一本核心介紹書籍 x86 外的硬體平臺，畢竟 RISC vs CISC 架構的不同, endianness, alignment, calling convention 等，應當有許多寫核心驅動程式應該注意得事項。但是整本書只在 2.2 節稍微說一下寫 Assembly 時，PowerPC, x86 的指令差異，剩下的細節根本沒提！

整本書還是著重在一般核心的結構介紹。

而書中除了少量的插圖之外，根本沒有沒有多少邏輯上的說明跟描述。通篇拆解程式碼，對資料結構作註解。這些資訊任何有點基礎的工程師都可自行閱讀程式碼及程式碼註解。新入門工程師還可能因爲書中解釋而疑惑。

除非你想寫沒有價值的書評，否則不建議購買。

Linux(R) Debugging and Performance Tuning: Tips and Techniques 出版於 2005, 作者是 Steve Best。此書少見的從除了應用程式之外，還從核心切入的除錯、效能測試書籍，因爲這方面的技術資訊總是一下就超過保鮮期。

作者試著含括基本的 Profiling 實務開始，介紹 gdb, 應用程式記憶體管理，再講核心的各種資訊界面。很可惜，以一本專講除錯與效能測試的書來說，範例與介紹過於粗淺，以第十二章 Dynamic Probes 為例，其介紹深度可能還比不上 Documents/kprobes.txt 中的概念介紹與 IBM developerWorks 的範例介紹。

適合剛切換到 Linux 的開發者，可概略學得各種基本開發工具者的入門資訊。

2011-03-17 18:00 更新

增列相關中譯版本連接，感謝 ansoncat 告知資訊。

2011-05-15 18:00 更新

修正 UTLK 版本為 2.6.11, 補充 ULNI 版本為 2.6.12. 感謝讀者 Wayling 指出錯誤。

Posted on
by

經過幾年發展，DBus 已經取代早年 Linux 桌面環境所用的 GNOME Bonobo, KDE DCOP，用於許多應用程式，成為主流 IPC 系統。隨著軟體原件逐漸成熟，眾多程式語言都已經支援 DBus APIs，DBus daemon 的 footprint 也逐漸能夠被嵌入式所接受，而被行動裝置作業系統如 MeeGo, WebOS 所採用。

Linux 開發者難免因爲介接需求，需要測試或使用 DBus 除錯。這裡分享幾個常用的小技巧。DBus 使用物件導向的 API 界面，所有 Services 的 Object 函式都是以 Method, Signals, Properties 的概念揭露給外界存取，配合 Introspectable API，很容易讓第三方介接。

最常用到的工具之一是 dbus-send，它可以用來從指令列測試接傳 DBus messages，像是列出系統上所有註冊在 Session Bus 的 Services

$ dbus-send --session --print-reply --reply-timeout=2000 \
--type=method_call --dest=org.freedesktop.DBus /org/freedesktop/DBus  \
org.freedesktop.DBus.ListActivatableNames

有了 Services 名稱，接下來你就可以用 Service 為名以 Introspection 界面去查詢其所開放之 API，如

$ dbus-send --session --print-reply --reply-timeout=2000 --type=method_call \
--dest=org.gnome.ScreenSaver / org.freedesktop.DBus.Introspectable.Introspect
method return sender=:1.7256 -> dest=:1.7286 reply_serial=2
 string "<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node>
 <interface name="org.freedesktop.DBus.Introspectable">
 <method name="Introspect">
 <arg name="data" direction="out" type="s"/>
 </method>
 </interface>
 <interface name="org.gnome.ScreenSaver">
 <method name="Lock">
 </method>
 <method name="Cycle">
 </method>
 <method name="SimulateUserActivity">
 </method>
 <method name="Inhibit">
 <arg name="application_name" direction="in" type="s"/>
 <arg name="reason" direction="in" type="s"/>
 <arg name="cookie" direction="out" type="u"/>
 </method>
 <method name="UnInhibit">
 <arg name="cookie" direction="in" type="u"/>
 </method>
 <method name="GetInhibitors">
 <arg name="list" direction="out" type="as"/>
 </method>
 <method name="Throttle">
 <arg name="application_name" direction="in" type="s"/>
 <arg name="reason" direction="in" type="s"/>
 <arg name="cookie" direction="out" type="u"/>
 </method>
 <method name="UnThrottle">
 <arg name="cookie" direction="in" type="u"/>
 </method>
 <method name="GetActive">
 <arg name="value" direction="out" type="b"/>
 </method>
 <method name="GetActiveTime">
 <arg name="seconds" direction="out" type="u"/>
 </method>
 <method name="SetActive">
 <arg name="value" direction="in" type="b"/>
 </method>
 <method name="ShowMessage">
 <arg name="summary" direction="in" type="s"/>
 <arg name="body" direction="in" type="s"/>
 <arg name="icon" direction="in" type="s"/>
 </method>
 <signal name="ActiveChanged">
 <arg name="new_value" type="b"/>
 </signal>
 </interface>
</node>
"
$ dbus-send --session --print-reply --reply-timeout=2000 \
--type=method_call --dest=org.gnome.Tomboy \
/org/gnome/Tomboy/RemoteControl org.freedesktop.DBus.Introspectable.Introspect

 string "<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<!-- NDesk.DBus 0.6.0 -->
<node>
 <interface name="org.freedesktop.DBus.Introspectable">
 <method name="Introspect">
 <arg name="data" direction="out" type="s" />
 </method>
 </interface>
 <interface name="org.gnome.Tomboy.RemoteControl">
 <method name="Version">
 <arg name="ret" direction="out" type="s" />
 </method>
 <method name="DisplayNote">
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="b" />
 </method>
 <method name="HideNote">
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="b" />
 </method>
 <method name="DisplayNoteWithSearch">
 <arg name="uri" direction="in" type="s" />
 <arg name="search" direction="in" type="s" />
 <arg name="ret" direction="out" type="b" />
 </method>
 <method name="FindNote">
 <arg name="linked_title" direction="in" type="s" />
 <arg name="ret" direction="out" type="s" />
 </method>
 <method name="FindStartHereNote">
 <arg name="ret" direction="out" type="s" />
 </method>
 <method name="CreateNote">
 <arg name="ret" direction="out" type="s" />
 </method>
 <method name="CreateNamedNote">
 <arg name="linked_title" direction="in" type="s" />
 <arg name="ret" direction="out" type="s" />
 </method>
 <method name="CreateNamedNoteWithUri">
 <arg name="linked_title" direction="in" type="s" />
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="s" />
 </method>
 <method name="DeleteNote">
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="b" />
 </method>
 <method name="DisplaySearch" />
 <method name="DisplaySearchWithText">
 <arg name="search_text" direction="in" type="s" />
 </method>
 <method name="NoteExists">
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="b" />
 </method>
 <method name="ListAllNotes">
 <arg name="ret" direction="out" type="as" />
 </method>
 <method name="GetNoteContents">
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="s" />
 </method>
 <method name="GetNoteTitle">
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="s" />
 </method>
 <method name="GetNoteCreateDate">
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="x" />
 </method>
 <method name="GetNoteChangeDate">
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="x" />
 </method>
 <method name="GetNoteContentsXml">
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="s" />
 </method>
 <method name="GetNoteCompleteXml">
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="s" />
 </method>
 <method name="SetNoteContents">
 <arg name="uri" direction="in" type="s" />
 <arg name="text_contents" direction="in" type="s" />
 <arg name="ret" direction="out" type="b" />
 </method>
 <method name="SetNoteContentsXml">
 <arg name="uri" direction="in" type="s" />
 <arg name="xml_contents" direction="in" type="s" />
 <arg name="ret" direction="out" type="b" />
 </method>
 <method name="SetNoteCompleteXml">
 <arg name="uri" direction="in" type="s" />
 <arg name="xml_contents" direction="in" type="s" />
 <arg name="ret" direction="out" type="b" />
 </method>
 <method name="GetTagsForNote">
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="as" />
 </method>
 <method name="AddTagToNote">
 <arg name="uri" direction="in" type="s" />
 <arg name="tag_name" direction="in" type="s" />
 <arg name="ret" direction="out" type="b" />
 </method>
 <method name="RemoveTagFromNote">
 <arg name="uri" direction="in" type="s" />
 <arg name="tag_name" direction="in" type="s" />
 <arg name="ret" direction="out" type="b" />
 </method>
 <method name="GetAllNotesWithTag">
 <arg name="tag_name" direction="in" type="s" />
 <arg name="ret" direction="out" type="as" />
 </method>
 <method name="GetNotebookForNote">
 <arg name="uri" direction="in" type="s" />
 <arg name="ret" direction="out" type="s" />
 </method>
 <method name="AddNoteToNotebook">
 <arg name="uri" direction="in" type="s" />
 <arg name="notebook_name" direction="in" type="s" />
 <arg name="ret" direction="out" type="b" />
 </method>
 <method name="GetAllNotesInNotebook">
 <arg name="notebook_name" direction="in" type="s" />
 <arg name="ret" direction="out" type="as" />
 </method>
 <method name="AddNotebook">
 <arg name="notebook_name" direction="in" type="s" />
 <arg name="ret" direction="out" type="b" />
 </method>
 <method name="SearchNotes">
 <arg name="query" direction="in" type="s" />
 <arg name="case_sensitive" direction="in" type="b" />
 <arg name="ret" direction="out" type="as" />
 </method>
 <signal name="NoteDeleted">
 <arg name="uri" direction="out" type="s" />
 <arg name="title" direction="out" type="s" />
 </signal>
 <signal name="NoteAdded">
 <arg name="uri" direction="out" type="s" />
 </signal>
 <signal name="NoteSaved">
 <arg name="uri" direction="out" type="s" />
 </signal>
 </interface>
</node>"

注意其中 object name 因各 Service 定義不同，首次查詢可從 / 開始查，Dbus 會答覆其子路徑。

有了 API 界面之後，就可以直接用 dbus-send 送些指令給這些 Services 啦。如下啟動螢幕保護程式。

dbus-send --session --dest=org.gnome.ScreenSaver \
--type=method_call --print-reply --reply-timeout=20000 \
/ org.gnome.ScreenSaver.SetActive boolean:true

參數的格式可參考 DBus 規格中的 Type Signatures。

如果你是在 Desktop 環境想查詢測試 DBus APIs, 比較容易的工具是使用 d-feet，這是 Python/GTK 所寫的工具，只消滑鼠點點就可以查詢各種 API 與送出指令訊息。(以下圖片出自 d-feet)

知道了基本的測試工具後，測試期間通常需要觀測訊息的傳送與反應是否正確，此時可以利用 dbus-monitor。它可以用來監測系統中所有的 Dbus messages，方便查詢軟體是否運作正常。

由於安全性的考量，dbus-monitor 預設只能監錄 Session Bus 中的訊息，意即在每個 Login session 中使用者所開啟的軟體。至於 System Bus，像是 Network Manager 等預設是無法存取的，這是避免惡意軟體竊取隱私，如密碼等資訊。

必須手動開啟權限，設定方法是更改以下設定檔，開啟 eavesdrop policy，並重啟 Dbus daemon. 這樣才能竊聽相關通訊。

cat > /etc/dbus-1/system-local.conf
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

  <policy context="default">
    <!-- All messages may be received by default -->
    <allow receive_requested_reply="false" receive_type="method_call" eavesdrop="true"/>
    <allow receive_requested_reply="false" receive_type="method_return" eavesdrop="true"/>
    <allow receive_requested_reply="false" receive_type="error" eavesdrop="true"/>
    <allow receive_requested_reply="false" receive_type="signal" eavesdrop="true"/>
    <allow eavesdrop="true"/>
  </policy>
  <policy user="root">
      <allow send_destination="*" eavesdrop="true"/>
      <allow receive_sender="*" eavesdrop="true"/>
  </policy>
</busconfig>

詳盡資訊請參考