上文我们从总体上把握了bluetoothd启动的流程,下面我们就具体的细节来详细分析一下,首先要看到的就是init_defaults,在它里面最重要也是最有意义的就是main.conf的解析了。我们通常需要修改某个配置就去修改main.conf中的内容,那么这些内容又是如何真正被配置呢?本文就来和你一一说来。
2.2.1 默认的初始化简介
这个函数会初始化一些默认的配置,在main.conf中没有修改的参数,将会使用这里定义的,当然,若是修改过了,那就只能使用这里的参数了
- static void init_defaults(void)
- {
- /* Default HCId settings */
- //默认的配置
- //这里的main_opts是一个全局变量
- memset(&main_opts, 0, sizeof(main_opts));
- main_opts.mode = MODE_CONNECTABLE; //可连接的
- main_opts.name = g_strdup("BlueZ");//名字是bluez
- main_opts.discovto = DEFAULT_DISCOVERABLE_TIMEOUT;//默认的可发现timeout是3分钟
- main_opts.remember_powered = TRUE;
- main_opts.reverse_sdp = TRUE;
- main_opts.name_resolv = TRUE; //需要remote name request
- main_opts.link_mode = HCI_LM_ACCEPT;
- //支持role swtich以sniff,hold和park状态了
- main_opts.link_policy = HCI_LP_RSWITCH | HCI_LP_SNIFF |
- HCI_LP_HOLD | HCI_LP_PARK;
- //这里就是获取主机的名字来作为host_name
- if (gethostname(main_opts.host_name, sizeof(main_opts.host_name) - 1) < 0)
- strcpy(main_opts.host_name, "noname");
- }
2.2.2glib命令行解析库的简单使用
这个方法使用的目的就是避免一个一个参数进行switch的解析,就像hciattach中写的那样,大家会发现那样去解析要写很大一段代码。glib库提供了一个库函数进行解析,他会根据一个GoptionEntry结构体进行自动地解析,先来看一下GoptionEntry结构体:
- typedef struct {
- const gchar *long_name; // 完整命令 如:--name
- gchar short_name; // 简写命令 如:-n
- gint flags; // GOptionFlags枚举的值
- GOptionArg arg; // GOptionArg枚举的值
- gpointer arg_data; // 解析出来的数据,所要存储的位置
- const gchar *description; // 参数描述,--help可以查看到
- const gchar *arg_description;
- } GOptionEntry;
这样一看就感觉到很清晰了吧,就是说我们解析命令行中的参数最终把它保存到arg_data中,我们只要事先实现这个结构体就万事大吉了。
回到我们的分析中来,我们这个结构体是实现在options中的,我们看一下它的定义:
- static GOptionEntry options[] = {
- { "debug", 'd', G_OPTION_FLAG_OPTIONAL_ARG,
- G_OPTION_ARG_CALLBACK, parse_debug,
- "Specify debug options to enable", "DEBUG" },
- { "plugin", 'p', 0, G_OPTION_ARG_STRING, &option_plugin,
- "Specify plugins to load", "NAME,..," },
- { "noplugin", 'P', 0, G_OPTION_ARG_STRING, &option_noplugin,
- "Specify plugins not to load", "NAME,..." },
- { "nodetach", 'n', G_OPTION_FLAG_REVERSE,
- G_OPTION_ARG_NONE, &option_detach,
- "Don't run as daemon in background" },
- { "version", 'v', 0, G_OPTION_ARG_NONE, &option_version,
- "Show version information and exit" },
- { "udev", 'u', 0, G_OPTION_ARG_NONE, &option_udev,
- "Run from udev mode of operation" },
- { NULL },
- };
所以,很清晰把,就是我们定义了一系列的参数比如-n,后面的参数就会被保存在parse_debug中,简单吧。
那么在我们想解析的时候该如何使用,并调用哪些函数呢?
首先你需要调用context =g_option_context_new(NULL);来创建一个goptioncontext,然后
调用g_option_context_add_main_entries(context,options, NULL);关联对应的GoptionEntry,下面就可以调用_option_context_parse(context, &argc, &argv, &err)来解析传入的参数了,需要注意的是,在最后不要忘了调用g_option_context_free来释放对应的goptioncontext,否则就会出现内存泄露的情况了。
2.2.3main.conf的解析
这个函数就是根据main.conf中的配置进行不同的设置。需要注意的是bluez中有一个main.conf的文件,然而android最终并没有使用这个文件,而是使用了system/bluetooth/data目录下的main.conf文件。
初略地去看一下,这个文件的内容其实蛮简单的,去除掉注释就是这样的:
- [General]
- Name = %m
- Class = 0x40020C
- DiscoverableTimeout = 120
- PairableTimeout = 0
- PageTimeout = 8192
- DiscoverSchedulerInterval = 30
- InitiallyPowered = true
- RememberPowered = false
- DeviceID = android:generic:1.5
- ReverseServiceDiscovery = true
- NameResolving = true
- DebugKeys = false
- EnableLE = false
- AttributeServer = false
- DefaultLinkPolicy = 7
下面我们就根据源码解析的代码来看一下这些参数都是什么意思
- static void parse_config(GKeyFile *config)
- {
- GError *err = NULL;
- char *str;
- int val;
- gboolean boolean;
- //首先肯定是文件要是存在的
- if (!config)
- return;
- DBG("parsing main.conf");
- //找到General下面的DiscoverableTimeout
- val = g_key_file_get_integer(config, "General",
- "DiscoverableTimeout", &err);
- if (err) {
- DBG("%s", err->message);
- g_clear_error(&err);
- } else {
- //设置main_opts中的discovto参数
- //同时把flags中的HCID_SET_DISCOVTO置位
- DBG("discovto=%d", val);
- main_opts.discovto = val;
- main_opts.flags |= 1 << HCID_SET_DISCOVTO;
- }
- ……
- //下面的代码就全部是类似的,不再相信分析
- //所以,都只是根据main.conf然后设置一些值,这些值将在后面才会真正用到,我们在用到的时候再来具体分析
- }
这样main.conf中的内容就被我们解析出来了,后面只要根据具体的内容做具体的配置就可以了。这些配置的值如何被使用的,我们在后面的文章中将一一介绍。