and的roid系统vold透析.pdf

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 的 细节，只要知道sysfs 能向用户层提供什么就行了。首先，我们要知道如何接收来自内核的 event.Netlink socket 大家应该不会陌生吧，socket 这套东西不仅能用于网络间的通讯， 也用能用于进程间的通讯，像这种内核态与用户沟通的活，自然也少不了它。关于这个部分， 我们将在Vold 通信仲介绍。关于Vold 的主要作用，如下图所示： MountService Java空间 command onEvent NativeDaemonConnector onEvent Command C++空间 Volume Daemon