提出小虫报告的最好的方法是使用在 Linux PCMCIA 信息站的超媒体新闻讯 息列表。这样可让其他人知道最新的问题有哪些 (并修改或改变方法 )。这 儿是小虫报告内应让有的资料：
probe 命令的输出信息。/etc/pcmcia 档或 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
来给我，我较希望你能把小虫报告贴到我的网站上，这样子其他人也都可以
看到。
PCMCIA 模块含有许多条件编译的除错码。 大部份的这些码都在前置处理器
PCMCIA_DEBUG 定义的控制下。如果它没被定义，除错码就不会被编译
。如果设定位 0，控制码会被编译进入但不会被启用。愈大的数字指定会变
得更冗长了。 以 PCMCIA_DEBUG 定义来建立的模块都会有个整数参数
pc_debug，它会控制它的输出之多寡。 这可以在模块被载入时加以调
整，在不需重新编译下使得输出可以被控制成以每个模块为单位了。
在 PCMCIA 供应版内的 debug_tools/ 子目录内有一些除错的工
具。 dump_tcic 和 dump_i365 两个公用程序会产生 PCMCIA 控
制器的完整暂存器的倾印，并且将许多暂存器信息的解码。如果你有对相关
的控制蕊片做存取的话， 这些信息最最有用的了。 dump_tuples
公用程序列出了卡片的 CIS (卡片信息结构 )，并将一些较重要的资料解码
出来。 dump_cisreg 公用程序显示卡片的本地端建构暂存器(local
configuration registers)资料。
有时候 memory_cs 内存卡驱动程序用来除错很好用。它可以与任何
的 PCMCIA 卡相连接，而且不会干扰到其他的驱动程序。它可以被用来对任
何卡片的属性内存或通用内存的直接存取。
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 内找到。
我决定若要供应所有的 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 套件小部份的改 版时就得升级一次。我也会试著通知哪些供应驱动程序的作者对于他们的驱 动程序需要更动的地方。
如果您使用的供应商版本提供系统建构工具程序使您须注意 PCMCIA 部份，
请使用在 /etc/pcmcia 内的 *.opts 文档来”挂上”
哪些功能。如果使用者编译及安装新版的 PCMCIA 套件时它们将不会被更动
。如果您修改了主建构手稿后再安装个新的 PCMCIA 套件时，这将会悄悄地
把您已自订的手稿给覆盖而中断您之前与建构工具间的连接。如果您不晓得
怎么来写个合适的选项手稿，您可以与我连络。
如果您能将您使用的供应商版本中有关 PCMCIA 套件的使用与本文件之不同 的地方写成文件将对其他的使用者以及我本人有助益的。特别是，请在文件 上付上启动手稿及建构手构的不同处。
如果您想做 Linux 供应版的 PCMCIA，最好也把非 PCMCIA 主要程序的其他 分享驱动程序一起包括进去。为了方便维护，我会尽力地将核心套件的大小 限制在一定范围内，除非有我觉得会被大家感兴趣的部份才会再加进去。如 前面所说，其他的驱动程序会被分开地供应。对于被整合和分开于核心部份 的驱动程序之界定是随意且有些是有其历史性的，因此我们不能以为它们在 品质上有任何的不同。
后记:
译者按: 在翻译本篇文章的过程中，共遇到二次翻译到一半而原作者修正文
件及重新编排的状况。因此，本译文可能有翻译不周延或错字之处，烦请发
现错误地方的朋友来信到
linuxer.bbs@cis.nctu.edu.tw
给我，以便修正，谢谢您!