记得在几年前，用U盘的方式还停留在插上U盘，在终端下手动mount U盘，使用完毕后还需要手动umount U盘，然后再拔下U盘。麻烦！
现在Linux系统对桌面的支持在突飞猛进着，特别是Gnome桌面环境在广大厂商的支持下，正迅速地崛起，向最好用的桌面环境发起冲击。KDE的势头也是不错的，虽然和Gnome相比似乎少了大公司的青睐（都是依赖qt惹的祸），但依靠其坚实的基础和庞大的用户群和开发者，也在不断地发展着。并且Gnome和KDE也一改以前的势不两立的局势，开始逐渐走到一起，商讨如何让用户更好的在各自的系统中更好地支持原本在对方系统上运行的软件，freedesktop组织就是为了这个目的而创建的。目前这个组织也逐渐的提出了一些被双方支持的标准，Dbus就是一个很好的例子。
步入正题吧！
缘起于"超越无限"问我有关的是不是只要装上udev，USB等移动存储设备就能实现自动挂载，我不是太清楚，所以就自己着手分析了一下。
在网上搜了一些资料后发，现网络上的资料比较陈旧了（没办法，开源作者都是比较激进的，一般都不怎么考虑向前兼容，文档一般都滞后于代码，不过，这样也能促进技术的革新，不至于被向前兼容的条条框框所羁绊），所以就自己边看文档边对代码。后来获知内核对PNP设备的支持在Linux-2.6.15的时侯就不再采用陈旧的调用/sbin/hotplug的方式来实现了，后来也去除了udev对hotplug的依赖，截止到写这篇blog为止，整体的结构如下所示：
以KDE环境为例，目前对U盘的自动挂载主要是通过udev，hal和ivman三个守护进程实现的，dbusd在其中起到了消息路由器的功能。
USB盘自动挂载的流程如下：
- 当Kernel监测到有新的设备接入计算机系统时它通过netlink套接字向用户空间广播消息，通告有新的设备连入计算机。
- udevd守护进程将接收这个消息，并根据用户制定的策略采取相应的动作，比如说在/dev/目录下创建相应的设备文件以备用户空间的程序通过它和设备进行通信，加载此设备所需的驱动，执行一个特定的命令等等。在这里hal向udev添加一条规则，使它当有新设备时通过dbusd向hald发送一个消息。
- hald接收到来自udev的消息，然后根据用户的规则采取一系列的动作，因为ivman对添加设备的事件比较感兴趣，所以hald会接着将消息传递给ivman。
- ivman最终接收到这个消息，这个时侯她将采取一些用户可见的动作，比如说在applet上显示一个U盘样的图标，并且打开kopete将所在目录打开，或者是询问用户用什么打开U盘啦，诸如此类很GUI东东。
大家也许会问，怎么不停地接力传递消息，直接一步到位完了。实际上，当然可以一步到位了，如果你是使用的嵌入式设备，你完全可以在udev的策略里面加上一条规则，当出现/dev/sdxx的时侯，创建相应目录，并且挂载U盘，没有什么不可以的。那为什么整个系统要搞得如此复杂啊？答案就是为了兼容性。当然也有UNIX的程序设计哲学：“每次只作一件事，并把事情做到最好"，不过在这里不是特别明显。我们不要忘记了，在这个世界上还有很多其他UNIX系列的机器，比如AIX，HP-UNIX，BSD等了;并且可供选择的桌面环境也有两套（xfce等小规模桌面不算的话），并且用户群都很巨大。hal存在的原因就是为了隔离各个操作系统内部的差异，展现给其上层一个统一的硬件视图，而dbus这个消息路由器也是为了给所有桌面环境提供一个统一的接口。至于udev和ivman分别对应于Linux内核和kde桌面的一个特例。明白了这些，整个的系统结构你也就清楚了。
另外还有一个问题，以前内核通过调用用户空间的程序来发布硬件添加和删除的公告，现在改成了用netlink广播消息的方式，为此我们不得不付出一个守护进程的代价，这样真的值得么？我想内核采用如此的策略可能是因为内核直接调用用户空间程序多少显得有些粗鲁的原因，出于安全方面的考量么？
最后，本文并非介绍以上的软件如何配置，如有需要，go to google for help，需要提醒大家的是文档并不是总有效，一切都再不断的运动和变化中，包括此篇文章!
阅读(2555) | 评论(2) | 转发(0) |
