hald，好滴。

这个hald一点也不好滴。

尤其是底层接口，这个接口很重要，设计到电池充放电的各种状态和统计量。

把这层搞明白了，下面的13892就好捋了。 

近到hald/linux/osspec.c中，可以看到，这明显是OS-Specific 的含义。

在这层中可以看到,hald创建了一个socket用来听消息，来自udev的消息。

并且用g_io_channel 和 g_io_add_watch来添加和回调函数。

这个回调函数就是hald_udev_data,这个函数在受到消息后生成了hotplug_event。

这个event之后被广为传送。

 当然这个传送很简单，就是一个queue：hotplug_event_enqueue();

这个queue的处理在hotplug.c中，有一个hotplug_process_queue。

之后是hotplug_queue_begin,可以看到，这个函数里，对各种hotplug_event进行了分门别类的处理。

就pm而言，其中sys和apm都有接口。

问题在于，我们的系统中两种接口都有，这样会不会引起混乱呢？。。。。

所以我还是倾向于sys接口。

hotplug_event_begin_add()是在hotplug_event_begin函数中专门用来处理add事件的。

当然这个函数根本就不存在，而是实现了不同版本，对于sys而言，就是hotplug_event_begin_add_dev()。

 最贴心的地方马上就要发生啦：就在此时：dev在此文件中被分类了，估计就是根据/sys/class来的，每个类有一个handler

比如我们比较关心的power_supply就有如下dev_handler_power 。

这些handler组成一个数组，每次add remove等等事件中，都轮询一遍该数组。

每个handler又包含add , remove refresh 三个函数。

主要是用来更新数据库。

这样基本就万事大吉了。

可以放心hal这层了，而专注BSP了。

同时hal这层还真是不错，就是命名规则和文档不怎么多，小博也算是小推一下，另外代码也要学学。

话说hal的代码写的还是稍乱滴。。。

有了hald的框架，就很容易勾勒出电池管理程序的一个框架：

检测充电器插拔状态，检测电池插拔状态。（可能会有直充启动的情况）。

通过库仑计轮询，累计计算电量：这个环节最关键也最难实现，首先，是取得的值是增量还是绝对值。

显然是后者，这样就很好说了，维持一个最大值就好了，问题在于。。。这个值可能是负的么？