Next Previous Contents

7. 除錯小技巧及程式設計資訊

7.1 提出有用的小虫報告

提出小虫報告的最好的方法是使用在 Linux PCMCIA 資訊站的超媒體新聞訊 息列表。這樣可讓其他人知道最新的問題有哪些 (並修改或改變方法 )。這 兒是小虫報告內應讓有的資料:

所有的 PCMCIA 程式模組和 cardmgr 精靈所傳到系統日誌檔的訊息。 通常為 /var/log/messages/usr/adm/messages。 當追蹤一個問題時這應該時第一個要察看的地方。當您提出小虫報告時請連 同包括這個檔案。 如果您在找系統訊息有任何問題時, 請檢查 /etc/syslogd.conf 來看有哪些不同的訊息類別被處理了。

在提出小虫報告前,請您檢查一下確認您使用的是最新版的驅動程式套件。 如果能先看已被我改正除錯後的報告的話會讓人稍稍高興一下,不然就有點 沒建設性地辜負我的心血了。

如果你的問題是核心的部份,從錯誤的地方之錯誤傾印只有你能夠追縱錯誤 位址- EIP 才有用。 如果錯誤是在主要核心內,看看在 System.map 內的位址,找出錯誤的功能函數。如果出錯的地方是在可載入式模組內,那 麼就很難追縱了。 使用目前的模組工具 ``ksyms -m'' 會提出一份每 一個可載入模組的基位址。選取包含了 EIP 位址的模組,然後把 EIP 減掉 基位址即可獲得模組內的位移。 然後, 執行 gdb 在該模組上,使用 list 命令找到位移。 這項功能只有在你有使用 -g 選項在編譯 該模組時加入了除錯資訊的功能。

如果你沒有使用網路,小虫報告也可以寄到 dhinds@hyper.stanford.edu 來給我,我較希望你能把小虫報告貼到我的網站上,這樣子其他人也都可以 看到。

7.2 低階 PCMCIA 除錯輔助

PCMCIA 模組含有許多條件編譯的除錯碼。 大部份的這些碼都在前置處理器 PCMCIA_DEBUG 定義的控制下。如果它沒被定義,除錯碼就不會被編譯 。如果設定位 0,控制碼會被編譯進入但不會被啟用。愈大的數字指定會變 得更冗長了。 以 PCMCIA_DEBUG 定義來建立的模組都會有個整數參數 pc_debug,它會控制它的輸出之多寡。 這可以在模組被載入時加以調 整,在不需重新編譯下使得輸出可以被控制成以每個模組為單位了。

在 PCMCIA 供應版內的 debug_tools/ 子目錄內有一些除錯的工 具。 dump_tcicdump_i365 兩個公用程式會產生 PCMCIA 控 制器的完整暫存器的傾印,並且將許多暫存器資訊的解碼。如果你有對相關 的控制晶片做存取的話, 這些資訊最最有用的了。 dump_tuples 公用程式列出了卡片的 CIS (卡片資訊結構 ),並將一些較重要的資料解碼 出來。 dump_cisreg 公用程式顯示卡片的本地端建構暫存器(local configuration registers)資料。

有時候 memory_cs 記憶體卡驅動程式用來除錯很好用。它可以與任何 的 PCMCIA 卡相連接,而且不會干擾到其他的驅動程式。它可以被用來對任 何卡片的屬性記憶體或通用記憶體的直接存取。

7.3 為新卡片寫卡片服務驅動程式

Linux PCMCIA 程式設計師指引是 Linux PCMCIA 介面的最好文件。 最新的 版本你都可以從 hyper.stanford.edu/pub/pcmcia/doc 目錄內或是在網站 http://hyper.stanford.edu/HyperNews/get/pcmcia/home.html 內找到。

對於那些接近於一般的 ISA 介面設備來說, 你也許可以使用已存在的 Linux 驅動程式來驅動。有時候,最大的障礙是修改一個已存在的驅動程式 使它可以在開機後處理加入或移出設備。在現行的驅動程式中,只有記憶體 卡是唯一 `` 自我包含的 '' 驅動程式-並不依賴 Linux 的核心的其他部 份來做苦工。

在很多例子中,要支援一張新卡的最大障礙在於從它的製造版那兒得到技術 資訊。 要知道問誰才對或是解釋哪些資訊是必需的也很難。 然而, 只有少數例子外,在沒有從製造廠得到技術資訊的情況下要寫個該卡的驅動 程式幾乎很難。

我寫了一個含了備註來解說許多有關一個驅動程式如何與 Card 服務程式相 灌通的架構驅動程式。 你可以在 PCMCIA 原始檔案的 modules/skeleton.c 內找到。

7.4 給 PCMCIA 客戶自定驅動程式的作者的指引

我決定若要供應所有的 PCMCIA 客戶端驅動程式來成為 PCMCIA 套件的一部 份的話,這樣並不適合我。每一個新的驅動程式都會讓主要套件漸漸地難以 來維護。而且包含的這些驅動程式也會不請自來地將維護的工作從作者那兒 轉移到我的身上。因此,我會基於使用者的需求以及可維護性來以個案的方 式決定是否要包含哪些供應的驅動程式。對於那些不被包含在核心套裝的驅 動程式,我建議這些驅動程式的作者可以使用下面的方案來打包您的驅動程 式作為供應用。

驅動程式的檔案應該被安排放在與 PCMCIA 來源供應版商的相同目錄結構下 ,如此,驅動程式就可被解開到完整的 PCMCIA 原始程式樹的上面了。一個 驅動程式應該包含原始程式檔案 (在 ./modules/), man 頁 (在 ./man/),建構檔案 (在 ./etc/)。 在最上層的目錄內 也應該有個 README 讀我檔案。

最上層目錄也應該包含一個 makefile,它是一個組合用來執行 ``make -f ... all'' 以及 ``make -f... install'' 編譯驅動程式並安裝 適當的檔案。如果這個 makefile 有個 .mk 附加檔名,那麼它會自動 地被上層的 Makefile 命令加上 all 以及 install 目標 地時來執行。

以下是一個 makefile 如何被建立的例子:

# Sample Makefile for contributed client driver
FILES = sample_cs.mk README.sample_cs \
        modules/sample_cs.c modules/sample_cs.h \
        etc/sample etc/sample.opts man/sample_cs.4
all:
        $(MAKE) -C modules MODULES=sample_cs.o
install:
        $(MAKE) -C modules install-modules MODULES=sample_cs.o
        $(MAKE) -C etc install-clients CLIENTS=sample
        $(MAKE) -C man install-man4 MAN4=sample_cs.4
dist:
        tar czvf sample_cs.tar.gz $(FILES)

這個 makefile 使用 2.9.10 版本(含)以後的 PCMCIA 套裝程式所定義的 安裝目標地。它還包含了一個 ``dist'' 目標地來給驅動程式的作者方便性 。 你也許想要加上版本編號到最後的套裝檔名上。 (例如, sample_cs-1.5.tar.gz)。一個完整供應版可以如下:

sample_cs.mk
README.sample_cs
modules/sample_cs.c
modules/sample_cs.h
etc/sample
etc/sample.opts
man/sample_cs.4

以這樣的安排,當供應版本驅動程式被解開時,它會變為 PCMCIA 原始程式 樹的必要成員。這樣它就可以使用 PCMCIA 檔頭檔案以及檢查使用者系統建 構的機能、自動相關性檢查,就像是個 `` 一般的 '' 客戶端驅動程式一樣 。

我接受那些依照這個規格所準備的客戶端驅動程式將它們放在我的 FTP 檔 案傳輸站 hyper.stanford.edu/pub/pcmcia/contrib 目錄內。在這個目錄內的 README 檔案會述明如何解開供應的驅動程式。

PCMCIA 客戶端驅動程式介面一直以來都沒有變動很多, 並且還都有保留向 後相容的功能。一客戶端驅動程式並不需在主要的 PCMCIA 套件小部份的改 版時就得升級一次。我也會試著通知那些供應驅動程式的作者對於他們的驅 動程式需要更動的地方。

7.5 給 Linux 供應版本維護人員的導引

如果您使用的供應商版本提供系統建構工具程式使您須注意 PCMCIA 部份, 請使用在 /etc/pcmcia 內的 *.opts 檔案來”掛上” 那些功能。如果使用者編譯及安裝新版的 PCMCIA 套件時它們將不會被更動 。如果您修改了主建構手稿後再安裝個新的 PCMCIA 套件時,這將會悄悄地 把您已自訂的手稿給覆蓋而中斷您之前與建構工具間的連接。如果您不曉得 怎麼來寫個合適的選項手稿,您可以與我連絡。

如果您能將您使用的供應商版本中有關 PCMCIA 套件的使用與本文件之不同 的地方寫成文件將對其他的使用者以及我本人有助益的。特別是,請在文件 上付上啟動手稿及建構手構的不同處。

如果您想做 Linux 供應版的 PCMCIA,最好也把非 PCMCIA 主要程式的其他 分享驅動程式一起包括進去。為了方便維護,我會盡力地將核心套件的大小 限制在一定範圍內,除非有我覺得會被大家感興趣的部份才會再加進去。如 前面所說,其他的驅動程式會被分開地供應。對於被整合和分開於核心部份 的驅動程式之界定是隨意且有些是有其歷史性的,因此我們不能以為它們在 品質上有任何的不同。

後記:

譯者按: 在翻譯本篇文章的過程中,共遇到二次翻譯到一半而原作者修正文 件及重新編排的狀況。因此,本譯文可能有翻譯不周延或錯字之處,煩請發 現錯誤地方的朋友來信到 linuxer.bbs@cis.nctu.edu.tw 給我,以便修正,謝謝您!


Next Previous Contents