linux内核处理不带dev_t的设备号时，udev是如何处理的

gzzaigcn2012

貌似在device_add时，对不带dev_t的设备，通过kobject_uevent_env是不会上传设备号这个env的，但很奇怪的是用户端的进程在收到uevent时还是会去mknod?
看的是Android端init里面的uevent的源码。

疑问是 对于不带dev_t本质肯定是不需要创建设备节点的，看到内核device_add时，有devtmpfs_create_node和kobject_uevent_env两种方式，感觉都是会去创建设备节点。
还有对于无设备号的设备，难道device_add时，uevent也会去创建吗，理论肯定是不可能的，但没有看到相关的code去做分支处理。devtmpfs_create_node倒是很明显的做了分支？
请告知udev这个机制是如何处理不带设备号的设备add的。？

gzzaigcn2012

求帮分析一下呗

nswcfd

没太明白问题。
不带dev_t的设备，是指dev->devt为0么？

如果dev->devt为0的话（其实是major非0），那么sysfs里面，就没有dev这个属性了。

上传KOBJ_ADD事件时，缺省有ACTION/DEVPATH/SUBSYSTEM三个属性（就是环境变量啦），其它属性来自kset。
dev_uevent又会增加DEVTYPE/DRIVER等属性，如果devt非空，则增加MAJOIR/MINOR/DEVNAME/DEVMODE。
此外，dev所属的bus/class也会增加额外属性定义。

udev事件是一定会产生的，至于用户态怎么去解释，内核并不care。

PS，就算用户态会mknod，那dev_t(major:minor)总得有个来源吧？

gzzaigcn2012

回复 3# nswcfd

恩，感谢你的回答。
我看的是Android下uevent机制，目前了解到的是不带dev_t的uevent，Android的uevent进程是不mknod的。还有不是根据dev属性来处理的，而是写uevent属性文件来重新触发下层的kobject重发一次uevent事件。

gzzaigcn2012

回复 3# nswcfd

dev_t的来源就是你说的那种，有uevent_dev_ops来添加到uevent上传的环境变量中