针对某项目中QNX驱动的反思

第一次接触驱动层的东西，心里还有点小激动。总感觉自己比没搞之前提高了那么一点点，也不知是真的假的，拉出来遛遛。

1．整体思路

★驱动层

先从驱动层说起，他将USB设备通过Resource Manager注册成一个文件，提供 IO服务：

① ：通过USB控制接口登陆回调函数

② ：通过USB的回调函数“insertion”，也就是USB插入信号来生成ResourceManager。如果设备已经插入，驱动启动后会立刻受到“insertion”回调。

③ ：通过ResourceManager登陆的各种IO接口，提供IO服务。底层是用usb_io来访问USB设备。

★接口层

接口层通过解释设备中的数据协议，提供数据服务，主要有以下三种：

① 连接控制：通过连接接口控制app的接入，处理资源的获取和释放。

② 应答响应：通过各种操作接口提供数据服务，响应用户的请求。

③ 通知处理：通过通知接口及时反映系统的状态。

2．现实

虽然看起来还不错，但是实际运用的时候惨的一塌糊涂，那个各种不稳定啊，现在想起来心里还堵得慌。

这次失败在接口层的通知处理上，当时那位神人是这么搞得

・1秒一次的数据通知，在通知线程中实现

・数据的发送/应答在客户线程中实现

・极品的来了，通知处理和应答处理各自访问设备文件。

应答线程的处理是这样的

⇒通知→转发通知→继续收

⇒本消息的应答→返回

⇒其他消息→无视→继续收

通知线程的处理是这样的

⇒通知→发通知→继续收

⇒其他消息→无视→继续收

问题出来了，只要设备的连接不稳定，那消息是各种丢啊。最后没办法，系统只能频繁的通过重新连接来恢复。

3．反思

再有机会的话要这样：

・通知处理与应答处理应该使用共通的IO层。受到的消息到哪里去由IO层决定。这样消息就不会莫名其妙的消息被丢掉了。

・应答处理中实现消息堆栈。虽然正常状况下消息是一个一个来得，但总是会有一些意外的，为了能在意外发生时保持正常，就要看看自己到底发了啥，来得是真的错误消息，还是其他消息的应答。