我最近在调试Android系统的gadget功能,通过make menuconfig发现gadget是编译成module模式的。里面有很多可选项,其中有个Android的选项,其实就是提供ADB和Storage的功能的。
具体查看代码在/drivers/usb/gadget下,三个文件:android.c f_adb.c f_mass_storage.c
g_android.ko 是由这三个文件而来,其中android.c 依赖于f_adb.c 和f_mass_storage.c(这两个文件之间无依赖关系)
可以在android.c中的
看到关系
============================================================
下面说说我的问题,
1.当我将Android编译成module模式,既g_android.ko时候,然后放入rootfs中手动加载,Okay, no problem!非常happy。但是,当我关闭adb进程,rmmod g_android的时候,出现死锁状态,打开代码进行查询,发现问题出现在
一直死锁,通过打开kernel hacking中的spinlock debug发现 是自己把自己锁了,找阿找阿。。。。
看了下rmmod时候 函数调用过程当我rmmod的时候,首先会去执行__exit cleanup(void)中的usb_composite_unregister(&android_usb_driver)这句话中还调用composite.c中的函数 (不细说),反正最后会调到f_adb.c中的
adb_function_unbind(struct usb_configuration *c, struct usb_function *f)
看看这个函数
所以感觉 req_get代码中的spinlock有问题,没办法,只能写了个req_get_free_lock(不加锁)替代while循环中的req_get函数
rebuild 内核,Okay 卸载g_android.ko 没问题 哈哈。正当自己高兴的时候,发现乐极生悲了。。。
===========================================================
卸载完了g_android.ko 我再次insmod g_android.ko 挂了,不过不是kernel panic而是提示
"sysfs: duplicate filename 'usb_mass_storage' can not be created"
恩 这次出在f_mass_storage.c这个文件中,根据信息提示应该是没因为上次没卸载完全。没办法,在几个与insmod和rmmod的函数中加入打印信息。主要是mass_storage_function_add, fsg_function_bind,fsg_function_unbind三个函数,前两个是跟insmod有关,后者跟rmmod有关。
通过打印信息发现一个Android开发者的 小纰漏 导致的问题,就是在
在掉用过/drivers/switch/class_switch.c 中的 switch_dev_register后,除了出错处理再也没作擦屁股的动作(unregister)汗,这不是占着XX不拉什么吗?没办法,去fsg_function_unbind函数中的
Okay 万事Okay 主阿!其实都不是什么大的问题拉。但是导致的现象确很恐怖。android developer太忙了,毕竟也是人阿。呵呵,以前都不敢改他们代码,总是推敲自己是不是哪边错了。想报bug去android开发者论坛,但是被该死的河蟹给和谐了,打不开report issue界面。感谢伟大的政府让我们这些P民,成为白痴和弱智。
草泥马的 !