标签归档：内核

fedora 14 下linux内核模块命令运行出错：安装软件包“module-init-tools”以提供命令“lsmod”？ 事务失败: all-packages-already-installed, The packages are already all installed

发表于由
1

fedora 14 下运行linux内核模块命令lsmod，出错，说没有该命令，需要安装，但运行安装命令又说命令已经安装，但lsmod就是还不能运行，如下：
command not found...
安装软件包“module-init-tools”以提供命令“lsmod”？ [N/y] ｛输入y回车｝
* 正在运行.. 事务失败: all-packages-already-installed, The packages are already all installed
yum install安装，提示说已经安装，于是yum reinstall，重新覆盖安装，得以解决。不过fedora14里，好像安装上的module-init-tools是fedora13版本里的包module-init-tools-3.11.1-2.fc13.i686 这并不影响使用

[root@fsc feng]# yum reinstall module-init-tools

----------------------------------------------------
以下是命令行输出，仅作参考

[root@fsc feng]# lsmod |grep 8169
bash: lsmod: command not found...
[root@fsc feng]# lsmod
bash: lsmod: command not found...
安装软件包“module-init-tools”以提供命令“lsmod”？ [N/y]
* 正在运行.. 事务失败: all-packages-already-installed, The packages are already all installed

[root@fsc feng]# lsmod
bash: lsmod: command not found...
安装软件包“module-init-tools”以提供命令“lsmod”？ [N/y]
* 正在运行.. 事务失败: all-packages-already-installed, The packages are already all installed

[root@fsc feng]# whereis lsmod
lsmod: /sbin/lsmod /usr/share/man/man8/lsmod.8.gz
[root@fsc feng]# yum install module-init-tools
已加载插件：langpacks, presto, refresh-packagekit
Adding zh_CN to language list
设置安装进程
包 module-init-tools-3.11.1-2.fc13.i686 已安装并且是最新版本
无须任何处理
[root@fsc feng]# yum reinstall module-init-tools
已加载插件：langpacks, presto, refresh-packagekit
Adding zh_CN to language list
设置覆盖安装进程
解决依赖关系
--> 执行事务检查
---> 软件包 module-init-tools.i686 0:3.11.1-2.fc13 将被 reinstalled
--> 完成依赖关系计算

依赖关系解决

================================================================================
软件包 架构 版本 仓库 大小
================================================================================
Reinstalling:
module-init-tools i686 3.11.1-2.fc13 fedora 412 k

事务概要
================================================================================
Reinstall 1 Package(s)

总下载量：412 k
Installed size: 939 k
确定吗？[y/N]：y
下载软件包：
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 412 k
module-init-tools-3.11.1-2.fc13.i686.rpm | 412 kB 00:07
运行 rpm_check_debug
执行事务测试
事务测试成功
执行事务
正在安装 : module-init-tools-3.11.1-2.fc13.i686 1/1

已安装:
module-init-tools.i686 0:3.11.1-2.fc13

完毕！
[root@fsc feng]# lsmod
Module Size Used by
vfat 6758 1
fat 38062 1 vfat
fuse 51544 9
ebtable_nat 1431 0
ebtables 12142 1 ebtable_nat
ipt_MASQUERADE 1765 3
iptable_nat 3945 1
nf_nat 16298 2 ipt_MASQUERADE,iptable_nat
bridge 57131 0
stp 1438 1 bridge
llc 3754 2 bridge,stp
deflate 1543 0
zlib_deflate 16199 1 deflate
ctr 2953 0
camellia 17759 0
cast5 15276 0
rmd160 6136 0
crypto_null 2142 0
ccm 6285 0
serpent 18049 0
blowfish 7246 0
twofish 5395 0
twofish_common 12658 1 twofish
xcbc 1991 0
cbc 2161 0
sha256_generic 11347 0
sha512_generic 6638 0
des_generic 15895 0
aes_i586 7138 0
geode_aes 4245 0
aes_generic 26460 1 aes_i586
ah6 4471 0
ah4 3939 0
esp6 3905 0
esp4 4104 0
xfrm4_mode_beet 1610 0
xfrm4_tunnel 1439 0
tunnel4 2005 1 xfrm4_tunnel
xfrm4_mode_tunnel 1418 0
xfrm4_mode_transport 981 0
xfrm6_mode_transport 1013 0
xfrm6_mode_ro 858 0
xfrm6_mode_beet 1423 0
xfrm6_mode_tunnel 1455 0
ipcomp 1585 0
ipcomp6 1602 0
xfrm_ipcomp 3353 2 ipcomp,ipcomp6
xfrm6_tunnel 3145 1 ipcomp6
tunnel6 1880 1 xfrm6_tunnel
af_key 22999 0
vmnet 35410 13
ppdev 6808 0
parport_pc 17897 0
parport 26215 2 ppdev,parport_pc
vmblock 9826 1
vsock 31975 0
vmci 45322 1 vsock
vmmon 58828 0
cpufreq_ondemand 7262 2
acpi_cpufreq 6285 0
mperf 1141 1 acpi_cpufreq
capi 10620 0
capifs 2374 2 capi
kernelcapi 28157 1 capi
ip6t_REJECT 3470 2
nf_conntrack_ipv6 14441 2
ip6table_filter 1207 1
ip6_tables 9929 1 ip6table_filter
ipv6 229581 45 ah6,esp6,xfrm6_mode_beet,xfrm6_mode_tunnel,ipcomp6,xfrm6_tunnel,tunnel6,ip6t_REJECT,nf_conntrack_ipv6
uinput 5228 0
snd_hda_codec_si3054 2988 1
snd_hda_codec_analog 53890 1
snd_hda_intel 20127 2
arc4 1085 2
snd_hda_codec 71701 3 snd_hda_codec_si3054,snd_hda_codec_analog,snd_hda_intel
snd_hwdep 4795 1 snd_hda_codec
ecb 1595 2
snd_seq 43447 0
snd_seq_device 5056 1 snd_seq
snd_pcm 61769 3 snd_hda_codec_si3054,snd_hda_intel,snd_hda_codec
gspca_vc032x 24940 0
gspca_main 19038 1 gspca_vc032x
r8169 31809 0
ath5k 143237 0
videodev 54469 1 gspca_main
snd_timer 15435 2 snd_seq,snd_pcm
snd 47365 13 snd_hda_codec_si3054,snd_hda_codec_analog,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer
v4l1_compat 11390 1 videodev
mac80211 188648 1 ath5k
asus_laptop 12297 0
iTCO_wdt 8960 0
soundcore 5088 1 snd
iTCO_vendor_support 2070 1 iTCO_wdt
ath 7145 1 ath5k
snd_page_alloc 6180 2 snd_hda_intel,snd_pcm
cfg80211 110951 3 ath5k,mac80211,ath
r852 8298 0
sparse_keymap 2472 1 asus_laptop
serio_raw 3589 0
joydev 7306 0
mii 3578 1 r8169
sm_common 3104 1 r852
nand 28994 2 r852,sm_common
nand_ids 2730 1 nand
nand_ecc 3460 1 nand
mtd 15282 2 sm_common,nand
rfkill 13652 3 asus_laptop,cfg80211
microcode 11139 0
irda 87797 0
crc_ccitt 1237 1 irda
sdhci_pci 6246 0
sdhci 15685 1 sdhci_pci
firewire_ohci 17697 0
mmc_core 53202 1 sdhci
firewire_core 37873 1 firewire_ohci
crc_itu_t 1235 1 firewire_core
video 17730 0
output 1625 1 video
usb_storage 35519 0
radeon 556900 2
ttm 45014 1 radeon
drm_kms_helper 22278 1 radeon
drm 139288 4 radeon,ttm,drm_kms_helper
i2c_algo_bit 4197 1 radeon
i2c_core 21328 5 videodev,radeon,drm_kms_helper,drm,i2c_algo_bit
[root@fsc feng]# yum update module-init-tools
已加载插件：langpacks, presto, refresh-packagekit
Adding zh_CN to language list
设置更新进程
不升级任何软件包
[root@fsc feng]# modls |grep 8169
bash: modls: command not found...
[root@fsc feng]# lsmod |grep 8169
r8169 31809 0
mii 3578 1 r8169
[root@fsc feng]# modinfo r8169
filename: /lib/modules/2.6.35.10-74.fc14.i686/kernel/drivers/net/r8169.ko
version: 2.3LK-NAPI
license: GPL
description: RealTek RTL-8169 Gigabit Ethernet driver
author: Realtek and the Linux r8169 crew
srcversion: 922AC21C384AA7EE2321FEF
alias: pci:v00000001d00008168sv*sd00002410bc*sc*i*
alias: pci:v00001737d00001032sv*sd00000024bc*sc*i*
alias: pci:v000016ECd00000116sv*sd*bc*sc*i*
alias: pci:v00001259d0000C107sv*sd*bc*sc*i*
alias: pci:v00001186d00004300sv*sd*bc*sc*i*
alias: pci:v000010ECd00008169sv*sd*bc*sc*i*
alias: pci:v000010ECd00008168sv*sd*bc*sc*i*
alias: pci:v000010ECd00008167sv*sd*bc*sc*i*
alias: pci:v000010ECd00008136sv*sd*bc*sc*i*
alias: pci:v000010ECd00008129sv*sd*bc*sc*i*
depends: mii
vermagic: 2.6.35.10-74.fc14.i686 SMP mod_unload 686
parm: rx_copybreak:Copy breakpoint for copy-only-tiny-frames (int)
parm: use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot. (int)
parm: debug:Debug verbosity level (0=none, ..., 16=all) (int)
[root@fsc feng]#

现在的linux内核编译太简单了：linux kernel2.6.36.2编译手记

发表于由
回复

先show一下新内核：

[feng@fsc ~]$ uname -a
Linux fsc 2.6.36.2fsc #2 SMP Mon Dec 13 21:02:02 CST 2010 i686 i686 i386 GNU/Linux

硬件环境：asus A8jr 笔记本 （07年的机器，比较老了）

cpu core1 2250GHz
RAM 3G ddr2 667
VGA ATI x2300
......

背景：使用fedora13(fedora14已经正式版发布，但没有升级)，但内核还是2.6.31，从fedora12里的rpm包安装的；因为2.6.33以后的内核与电脑不兼容，启动后就花屏，跟电视机屏幕的“雪花”一样，所以从fedora12里释放出内核并安装。fedora13在线yum升级后，还切换回2.6.31内核。

kernel 2.6.36.2正式发布了，比较无聊，于是wget下载内核源码，学习编译内核；以前编译过，但并不很成功。学习鸟哥linux私房菜里的内核编译，写得很详细，基本上是照着里面一步一步来的。这次准备摸索一下。

首先当然是要make menuconfig，选择模块。然后make 没有带参数，花费时间很长，睡觉。

今天早上醒来，make install，然而出错了，消息大致是有什么依赖错误，可能是哪里有不对吧。于是关机（休眠），上班。

晚上回来，启动电脑，发现grub里启动项多了一个，就是新编译的2.6.36.2，居然可以启动系统，只是驱动不太对，没有网络，无线有线都没有;lsmod查看加载的模块，结果一个都没有，大概是驱动没有加载，或者是没有编译出来。为了保险起见，重新配置，添加了很多驱动。回忆之前看鸟哥的文章，make all，这样最简单，看make help里指明，它将编译

* vmlinux      - Build the bare kernel
* modules      - Build all modules
* bzImage      - Compressed kernel image (arch/x86/boot/bzImage)

三项，花费时间还是比较长；然后make install，重启，还是没有加载上驱动，看说明，才知道，make install并不安装内核模拟，于是make modules_install；重启。本来做好了面对“花屏”，然而没有。果然，网络正常，无线自动连上，可以正常上网。

之前看鸟哥文章里讲的，要手工复制内核到/boot，还要手工编译initrd文件，再手工修改grub.conf，很是复杂。这次编译内核，完全是出乎意料，所有这些都没做，只是简单的执行了几个命令，所有这些都自动完成了。这大概也就是“易用”吧。不过还是有点问题，linux启动中，vmware的几个服务，还是启动失败，原因没有查，可能按现在的水平还很难找到原因。

一点经验，linux其实很容易，甚至比windows更容易，当然不是在像傻瓜操作的那些方面。

最后，希望看过这篇文章或没有看到这篇文章的朋友们，都能真正爱上linux，能随心所欲使用它提高工作生活学习效率，have fun！

Solaris、Linux和FreeBSD的内核比较

发表于由
回复

1。我个人认为作者MAX对Linux的了解不像他对Solaris那样深入，我不知道也没法知道他的下列关于Linux的内容来自自己的代码阅读分析还是只是来自第三方的文档资料而未经自己实地验证；
2。我已经尽量符合原意地翻译了，当然中间实在忍不住的地方也插两句自己的话；
3。无论是只阅读这一篇文章，还是看其他东西，我都觉得，保持自己头脑清醒很重要；
4。谢谢

Max Bruning 是一名教师/资讯专家，他的教授内容包括Solaris内部组织，设备驱动，内核和应用的crash分析及调试，网络组织和其他一些特定科目（他的 blog在blogspot，不费点劲可能访问不了，所以也可以看看www.bruningsystems.com）。

在解释这些子系统在Solaris中是如何实现的时候，他的学生们总会问“Linux里它是怎么工作的？”或者“FreeBSD里是这 样，Solaris里呢？”这种经历最终让Max在OpenSolaris网站写了这篇A Comparison of Solaris, Linux, and FreeBSD Kernels。

文章里讨论了调度，内存管理和文件系统架构－－这3个子系统在任何操作系统中都有普遍应用，而且他们是最well-understood 的组件。

目前很多分析或对比文章所引用的材料及代码都比较老，与现实脱节，Max推荐如下几个多少比较up to date的网站：

Solaris Vs. Linux
Comparing MySQL Performance
Fast Track to Solaris 10 Adoption
Solaris 10 Heads for Linux Territory

其实抛开3个系统之间的差别，他们也有很多相似之处。除了那些不同的命名习惯，这些OS在实现不同概念的时候采用了非常相似的方法。他们都支持 线程的分时调度，支持最近未使用页面替换算法实现请求调页，支持虚拟文件系统层允许不同文件系统架构。这个系统里的一个好概念在另一个系统里也会采用。比 如Linux也接受并实现了 Solaris slab 内存分配算法的概念。FreeBSD 代码里的很多术语在Solaris里也出现了（快去看看代码。。。）。考虑到这3个系统的源代码都能得到了， fxr.watson.org提供了系统源码的交叉阅读浏览，可能会发现很多有趣的地方。

好了，温情默默的套近乎结束，进入正题。

调度和调度器

Solaris的调度单位是kthread_t，FreeBSd是thread，Linux是task_struct。抬高一级，Solaris的进程是proc_t，当然每个进程里的线程就是kthread_t；Linux的进程和线程都由task_struct 表示，单线程的进程在Linux里是一个task_struct。单线程的进程在Solaris里有一个proc_t，一个kthread_t，还有一个klwp_t表示。klwp_t提供了用户和内核模式线程切换的存储区。FreeBSD里的单线程进程有一个proc ，一个thread 和一个ksegrp 。ksegrp 是“内核调度的实体组kernel scheduling entity group”。三个系统的线程表示结构不同，不过都支持调度线程。

和大家熟悉的基本一样，调度是基于优先级的。小小的数学问题是，在Linux和FreeBSD里，数字越小，优先级越高；而SUN的宝贝却喜欢数字越大，优先级越高。参考下表

三个系统都更推崇interactive 线程/进程（下面会提到interactive怎么回事）。Interactive 线程比compute-bound 线程优先级要高，不过得到的时间片要少一些。Solaris，FreeBSD和Linux都使用每CPU的“运行队列 runqueue”。FreeBSD和Linux有一个active队列和一个expired队列。名字说得很清楚了－－系统从active上按照优先级 选择线程进行调度。用完自己时间片的线程就从active搬到expired上（或者为了避免“饿死”的其他情况），active空以后，内核交换 active和expired。FreeBSD还多一个idle 队列－－其他两个queue都空的时候才轮到这个。Solaris的概念是每CPU“调度队列 dispatch queue”。线程用完时间片后，内核给其一个新优先级然后放回调度队列。所有3个系统的runqueue，对不同优先级的可运行线程都分别有链表。

FreeBSD四个优先级共享一个链表，Solaris和Linux则每个优先级一个链表Linux和FreeBSD结合运行时间和睡眠时间计 算线程的interactive-ness，Solaris查表。他们都不支持“gang scheduling”（有兴趣查Google即知，并行计算上的调度算法，大白话说就是一组任务一把disptach到各个CPU上。劳伦斯.利弗莫尔 那帮造原子弹的家伙最喜欢了，他们有世界上最昂贵的玩具，可以理解）每个OS都调度下一个线程而不是N个线程开始运行。这3个OS都有利用 CACHE（warm affinity）和负载均衡的机制。对超线程CPU，FreeBSD能尽量将多个线程保持在一个CPU节点上（当然可能是不同的CPU超线程上）。 Solaris也有类似机制，不过是在用户和应用的控制下，而且并不限于CPU的超线程，他们的术语是processor sets，FreeBSD的叫法是processor groups和其他2个OS最大的不同是，Solaris同时支持多个“scheduling classes”。3个OS都支持POSIX的SCHED_FIFO，SCHED_RR和SCHED_OTHER （或者SCHED_NORMAL）。SCHED_FIFO 和SCHED_RR通常支持实时线程（我不同意。。。但是照翻。。。）。

Solaris和Linux为支持实时线程都支持了内核抢占。Solaris支持fixed priority类，system class的是系统线程（比如换页线程），interactive的是在X控制下运行窗口环境的线程，还有一个Fair Share Scheduler 用于资源管理。具体可以参考Solaris资料。FreeBSD的调度器是在编译时决定的，Linux的调度？－－要看版本了。
支持在系统中加 入新的调度类是要付出代价的。内核中每个可能决定调度的地方都得有一个间接得函数调用去call调度类相关的代码。比如，当一个线程将要sleep时，内 核调用调度类相关代码，完成该类中线程sleep需要完成工作。在Linux和FreeBSD上，调度已经完成了所有工作。不需要再来一个间接调用。额外 的层次，就意味着Solaris的调度要占用稍微多一点的系统开销－－不过提供了更多的功能。

内存管理和分页

Solaris的进程地址空间由逻辑段segment组成。进程地址中的这些段可以通过pmap访 问。Solaris将其内存管理代码和数据结构分为平台无关和平台相关部分（这不跟没说一样嘛。。。）。平台相关部分位于HAT（hardware address translation）层。FreeBSD用vmspace描述进程地址空间，将其划分为逻辑块region。硬件相关部分在 pmap（physical map）模块，而vmap 例程处理硬件无关部分和数据结构。Linux使用内存描述符划分进程地址空间，逻辑单位是memory areas。Linux也由pmap来examine 进程地址空间。

Linux将机器相关层从更高层次的机器无关层中划分出来。 Solaris和FreeBSD中大多数类似代码比如page fault处理是机器无关的，而Linux处理page fault的代码则非常机器相关－－从fault处理开始就是这样了。由此下来的结果是，Linux能很快地完成大多数分页相关代码－－因为数据抽象更 少。不过，代价是，下层硬件的改变需要大量修改代码－－Solaris和FreeBSD则分别把这样的工作堵截在HAT和pmap层搞定。

Segment，region和meory area的分割是：区域的虚拟地址segmetn/region/memory area映射的object/文件的位置权限map的大小
例如，程序的text（text段，即代码）在一个segmetn/region/memory area中，OS管理地址空间的机制是类似的，不过数据结构名字完全不同。
分页3个系统都使用了最近最少使用least recently used算法的变种完成页替换。他们都有一个守护daemon进程/线程完成页替换。FreeBSD的是vm_pageout daemon，它周期性地，或者当free的内存不多时，被唤醒。当可用内存低于某个限制时，vm_pageout 运行例程vm_pageout_scan扫描内存并释放一些页面。vm_pageout_scan例程可能需要异步地将更改过的页面写回到磁盘，在释放他们之前。不论由多少颗CPU，只有一个这样的daemon。Solaris的是pageout daemon，它也周期性地运行，处理空闲内存不多的情况。Solaris中的分页限制值在系统启动时自动校准，这样可以避免该守护进程过渡占用CPU或者向磁盘发出洪水般的换页请求（嗯，flood这么翻正好 ;P ）。

FreeBSD的daemon在大多数情况下使用的值是固定的－－不过也可以调整。Linux的LRU算法可以在运行时动态调整，而且可以有多个kswapd daemon，每CPU最多一个。这3个系统都使用global working set策略，而不是per process working set。FreeBSD有多个页面链表来追踪最近使用页。包括active，inactive，cached和feee页。根据使用情况，页面在这些链表 间走来走去。经常访问的页面会在active上。退出的进程的数据页面将被马上放到free上。

如果因为负载原因vm_pageout_scan 来不及扫描全部内存的话，FreeBSD内核可能将整个进程全部换出。如果内存短缺十分严重，vm_pageout_scan 可能会kill系统中最大的进程。Linux也使用不同的页面链表。物理内存被分为（多个）3重zone：一个DMA页面，一个普通页面，一个动态分配内 存页面。zone的实现很像由于x86架构限制而很产生的。页面在hot，cold和free链表间移动－－机制和FreeBSD的类似。经常用的页面在 hot上。可用页面则在cold或者free上。

SUN的大佬使用free链，哈希链，vnode页面链支持自己的LRU实现。后两者大致相当于FreeBSD和Linux的 active/hot链－－也是FreeBSD和Linux要扫描的链。Solaris要扫描的不是这两个对象，它用two-handed clock算法扫描全部页面（见Solaris Internals 或其他什么地方随你便）。大致方法是，两只手相隔固定举例，前面的手将page的引用位清空以作为标识，如果自此开始没有进程引用这个页，后面的手就释放这个页面（当然如果需要就写回磁盘）。

3个系统在分页时都考虑了NUMA本地性。他们都把IO buffer cache和虚拟内存页面的cache合并到一个系统页cache中。系统页cache用于读写文件已经被mmap了文件，还有应用的text段和data段。

文件系统

3个系统都使用数据抽象层向应用隐藏文件系统实现细节。就是用大家熟悉的open，close，read，write，stat， 等等系统调用访问文件，无论下层的文件数据的实现和组织如何。Solaris和FreeBSD把这种机制称为VFS（virtual file system），基本数据结构是vnode（virtual node）。Solaris和FreeBSD里每个被访问的文件都有一个赋给他们的vnode。除了generic 的文件信息外，vnode还包含到file-system-specific 信息的指针。Linux采用了详细的机制，也叫VFS（virtual file switch），文件系统无关的数据结构是inode。这个机构和vnode类似（小心：Solaris和FreeBSD也另有自己的inode－－是 UFS文件系统里file-system-dependent 的数据）。Linux还有两个不同的结构，一个用于文件操作，另一个用于inode操作。Solaris和FreeBSD将他们合并为vnode操作。

VFS允许在系统里实现多种文件系统。这意味着他们相互访问对方的文件系统没问题。只要相关的文件系统例程和数据结构已经被移植到VFS上。所有这3个系统都允许文件系统堆叠stacking。下表列出了每个OS实现的文件系统类型，不是全部哈。

结论

Solaris，FreeBSD和Linux显然都在从对方身上获益。随着 Solaris的开源，这种相互促进有望更快。Max个人已经感觉到Linux的变化是最快的。新技术被快速地集成进系统，只是文档和健壮性可能有点落 后。Linux有很多－－或者有时是看上去有很多－－开发者。FreeBSD则大概是（从某种意义上）3个系统中历史最长的。Solaris来自BSD Unix和AT&T Bell实验室Unix的结合，使用了更多数据抽象层，因而一般说来能更简便地支持更多功能。不过，内核中大多数这样的分层都没有文档描述。可能随着代码 的开放这一点会有所改善。至于他们的差别，最大的地方之一是page fault处理了。在Solaris中，发生page fault时，代码是从平台相关的trap handler开始执行的（以大家的智商，这好像不用说了吧。。。），然后会调用generic的as_fault例 程，这个例程判断发生page fault的segment，然后调用segment driver处理page fault。segment driver调用文件系统代码，后者再调用进驱动程序，换入页面。换入完成后，segment driver 调用HAT层来更新页表项。在Linux上，发生page fault后，内核调用的代码在会马上进入平台相关部分，这些处理可能更快，不过可能不太容易扩展和移植（后半段说得太省，不知道作者有没有真的研究过 Linux下对应的处理过程）。

内核观察和调试工具对正确理解系统行为有关键意义。在这方面，Solaris有kmdb，mdb和DTrace 。在开源之前，Max就对Solaris做过多年“反向工程”－－他发现解决问题的时候使用工具总比阅读代码来得快－－我也知道，不过得看什么场合，大家 可不要被他误导。Linux嘛，我看作者Max不太熟，所以认为没有太多工具。对FreeBSD，他也认为只是可以用GDB调试内核的 dump－－Liux也可以。