Android创建设备文件

1引言 

1.1编写目的 

这是一篇介绍Android启动时关于设备文件的加载生成过程。主要介绍android如何实现驱动设备文件如何实现自动生成。 

这是篇面向关注底层工程师的文档。 

1.2介绍 

本文介绍android在启动时如何自动生成驱动设备文件。 


1.3定义 

NA. 


1.4引用 

NA. 


2目前常用的几种加载方式 

目前常用的方式有：1.UDEV 2.MDEV 3.android 

2.1 Udev介绍 

PC的设备节点生成方式采用udev守护进程进行事件解析进而生成设备节点，通过系统调用mknod生成设备节点 

linux传统上使用静态设备创建的方法，在dev下创建了大量的节点，而不管这些节点相应的硬件设备是否存在。采用udev的方法，系统检测到设备才会去创建这些设备对应的节点. 

udev是依赖于sysfs的，当系统中添加一个新的设备后，内核检测到后就会产生一个hotplug event并查找/proc/sys/kernel/hotplug去找出管理设备连接的用户空间程序，若udev已经启动，内核会通知udev去检测sysfs中关于这个新设备的信息并创建设备节点。如/dev/vcs,在/sys/class/tty/vcs/dev存放的是”7:0”，既/dev/vcs的主次设备号。并且udev还会根据/etc/udev/rules.d中的规则文件实现一些相应的功能。 


2.2Mdev介绍 

Mdev:非android嵌入式Linux采用mdev 

mdev是busybox中的一个udev管理程序的一个精简版，他也可以实现设备节点的自动创建和设备的自动挂载，只是在实现的过程中有点差异，在发生热插拔时间的时候，mdev是被hotplug直接调用，这时mdev通过环境变量中的 ACTION 和 DEVPATH，来确定此次热插拔事件的动作以及影响了/sys中的那个目录。接着会看看这个目录中是否有“dev”的属性文件，如果有就利用这些信息为这个设备在/dev 下创建设备节点文件。 


2.3Android方式 

Android重新实现了不同于MDEV的方式来生成设备驱动文件，这是本文主要介绍的内容，后面将重点阐述Android实现的流程。 

3Android驱动设备文件加载方式 

Android没有采用嵌入式常用的MDEV用于驱动设备的加载，而是重新实现。 

3.1启动 

在启动脚本system/core/rootdir/init.rc中一开始就启动服务 

start ueventd 

这个服务的定义为 

service ueventd /sbin/ueventd 

class core 

critical 


那么ventd是如何生成的 

system/core/init/Android.mk 

# Make a symlink from /sbin/ueventd to /init 

SYMLINKS := $(TARGET_ROOT_OUT)/sbin/ueventd 


由此可见，ueventd是init的一个软链接，代码与init是一致的，那么init如何来区分两个的不同。 


system/core/init/init.c 

main函数中 

692 if (!strcmp(basename(argv[0]), "ueventd")) 

693 return ueventd_main(argc, argv); 

argv[0]为当前执行程序的名字，在这里为ueventd，因此逻辑在这里分裂成两个单独的主程序。下面重点介绍下ueventd相关的流程。 


3.2驱动设备文件加载流程 

上一节中介绍了如何启动ueventd,本节主要介绍下ueventd的流程。 


system/core/init/ueventd.c 

int ueventd_main(int argc, char **argv) 

该函数主要有两个步骤，解析脚本并添加到设备属性列表待用，通过SYS添加驱动设备文件。 


1.解析ueventd.rc 

ueventd_parse_config_file("/ueventd.rc"); 

snprintf(tmp, sizeof(tmp), "/ueventd.%s.rc", hardware); 

ueventd_parse_config_file(tmp); 

内容如： 

设备节点路径 属性 用户 组 

/dev/full 0666 root root 

读取ueventd.rc 

system/core/init/ueventd_parser.c 

int ueventd_parse_config_file(const char *fn) 

parse_config(fn, data); 

解析ueventd.rc 

static void parse_config(const char *fn, char *s) 

state.parse_line = parse_line_device; 

state.parse_line(&state, nargs, args); 

解析后的ueventd.rc的内容 

static void parse_line_device(struct parse_state *state, int nargs, char **args); 

set_device_permission(nargs, args); 

添加设备属性 

system/core/init/ueventd.c 

void set_device_permission(int nargs, char **args) 

add_dev_perms(name, attr, perm, uid, gid, prefix); 

system/core/init/devices.c 

通过函数 

int add_dev_perms(const char *name, const char *attr, 

mode_t perm, unsigned int uid, unsigned int gid, 

unsigned short prefix)  

将从ueventd.rc中解析的添加到设备属性列表中待用。 

if (attr) 

108 list_add_tail(&sys_perms, &node->plist); 

109 else 

110 list_add_tail(&dev_perms, &node->plist); 

2.通过sys文件系统的uevent产生驱动设备节点 

system/core/init/ueventd.c 

通过函数device_init(); 

创建一个uevent_socket节点 

device_fd = uevent_open_socket(64*1024, true); 

system/core/libcutils/uevent.c 

int uevent_open_socket(int buf_sz, bool passcred) 

s = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_KOBJECT_UEVENT); 

通过创建NETLINK_KOBJECT_UEVENT属性的socket 可以获取kernel中发出的NETLINK_KOBJECT_UEVENT相关的uevent 

然后将节点返回给ufd。 

ufd.fd = get_device_fd(); 

然后while(1) 

通过 POLL根据FD状态进行处理，主要是下面这个函数： 

handle_device_fd(); 

system/core/init/devices.c 

void handle_device_fd() 

通过static void parse_event(const char *msg, struct uevent *uevent)解析kernel发出的uevent. 

本文重点介绍设备文件，关注 

static void handle_device_event(struct uevent *uevent) 

585 {  

586 if (!strcmp(uevent->action,"add")) 

587 fixup_sys_perms(uevent->path); 

588  

589 if (!strncmp(uevent->subsystem, "block", 5)) { 

590 handle_block_device_event(uevent); 

591 } else if (!strncmp(uevent->subsystem, "platform", 8)) { 

592 handle_platform_device_event(uevent); 

593 } else {  

594 handle_generic_device_event(uevent);  

595 }  

596 }  

我们看下通用设备的处理 

static void handle_generic_device_event(struct uevent *uevent) 

解析设备文件的子系统类型，生成设备路径目录，最后调用 

handle_device(uevent->action, devpath, uevent->path, 0, 

uevent->major, uevent->minor, links); 

进行设备文件的处理 

438 static void handle_device(const char *action, const char *devpath, 

439 const char *path, int block, int major, int minor, char **links) 

440 { 

441 int i; 

442  

443 if(!strcmp(action, "add")) { 

444 make_device(devpath, path, block, major, minor); 

445 if (links) { 

446 for (i = 0; links[i]; i++) 

447 make_link(devpath, links[i]); 

448 } 

449 }  

450  

451 if(!strcmp(action, "remove")) { 

452 if (links) { 

453 for (i = 0; links[i]; i++) 

454 remove_link(devpath, links[i]); 

455 } 

456 unlink(devpath); 

457 } 

458  

459 if (links) { 

460 for (i = 0; links[i]; i++) 

461 free(links[i]); 

462 free(links); 

463 } 

464 } 
添加设备文件时通过make_device(devpath, path, block, major, minor); 
static void make_device(const char *path, 

176 const char *upath, 

177 int block, int major, int minor) 

178 {  

179 unsigned uid; 

180 unsigned gid; 

181 mode_t mode; 

182 dev_t dev; 

183  

184 mode = get_device_perm(path, &uid, &gid) | (block ? S_IFBLK : S_IFCHR); 

185 dev = makedev(major, minor); 

186 /* Temporarily change egid to avoid race condition setting the gid of the 

187 * device node. Unforunately changing the euid would prevent creation of 

188 * some device nodes, so the uid has to be set with chown() and is still 

189 * racy. Fixing the gid race at least fixed the issue with system_server 

190 * opening dynamic input devices under the AID_INPUT gid. */ 

191 setegid(gid); 

192 mknod(path, mode, dev); 

193 chown(path, uid, -1); 

194 setegid(AID_ROOT); 

195 } 

通过函数get_device_perm取出之前解析ueventd.rc时存留在dev_perms中的设备属性。 

最终通过系统调用mknod实现设备文件的生成。