• 当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，需要提醒大家的是文档并不是总有效，一切都再不断的运动和变化中，包括此篇文章!