USB Storage
1. Vold 简介
1.1 udev 的由来
udev 是 Linux2.6 内核里的一个功能，它替代了原来的 devfs，成为当前 Linux 预设
的设备管理工具。udev 以守护进程的形式运行，通过侦听内核发出来的 uevent 来管理
/dev 目录下的设备文件。不像之前的设备管理工具，udev 在用户空间 (user space) 运
行，而不在内核空间 (kernel space) 运行。
devfs 存在的主要的问题是它处理设备检测、创建和命名的方式，其中设备节点的命名可
能是最严重的问题。一般可接受的方式是，如果设备名 是可配置的，那么设备命名策略
应该由系统管理员决定，而不是由某些开发者强制规定。devfs 文件系统还存在竞争条件
(race conditions) 的问题，这是它天生的设计缺陷，不对内核做彻底的修改就无法修正这
个问题。所以 udef 应运而生。
udev 能够实现所有 devfs 实现的功能。具有以下优点：
1) dynamic replacement for /dev。作为 devfs 的替代者，传统的 devfs 不能动态
分配 major 和 minor 的值，而 major 和 minor 非常有限，很快就会用完了。 udev
能够像 DHCP 动态分配 IP 地址一样去动态分配 major 和 minor。
2) device naming。提供设备命名持久化的机制。传统设备命名方式不具直观性，像
/dev/hda1 这样的名字肯定没有 boot_disk 这样的名字直观。udev 能够像 DNS
解析域名一样去给设备指定一个有意义的名称。
3) API to access info about current system devices 。提供了一组易用的 API 去
操作 sysfs，避免重复实现同样的代码，
但 udev 运行在用户模式中，而 devfs 运行在内核中。udev 只支持 linux-2.6 内核，因
为 udev 严重依赖于 sysfs 文件系统提供的信息，而 sysfs 文件系统只在 linux-2.6 内核中
才有。
1.2 Vold 的产生
Vold 的全称是 Volume Daemon。在 android 中，取代 udev 的是 vold,我们这里不去过
多的讨论为什么 android 不继续使用 udev，但要知道 vold 的机制和 udev 是一样的，理
解了 udev,也就理解了 vold。android 一出生就没有尊守传统 linux 的许多标准，当然也
不能指望 udev 能很好的服务于 android。android 小区的选择是别起炉灶，为 android
定做一套 udev,这就是 vold 了。无论是 udev 还是 vold,都是基于 sysfs 的，sysfs 为内核
与用户层的通讯提供了一种全新的方式，并将这种方式加以规范。kernel 层能检测到有新
的设备接入，并能为之加载相应的驱动，但如何通知用户层呢？这就是 sysfs 的工作，内核
中的 sysfs 机制要求当有新的驱动加载时给用户层发送相应的 event.但这些 event 只尽告
知的义务，具体怎么处理，这就是 vold 的事了。对于用户层而言，我们无需关心 sysfs 的
android系统
vold分析
