关于camera 构架设计的一点看法

camera的构架目前来看有两种，一种是集中式管理，比如说建立一个引擎，引擎向上提供接口，向下管理所有模块。把camera的所有功能划分为不同的模块，又引擎统一管理。模块的结构就比较随意了，可以统一接口，也可以对每个模块实现不同的接口。引擎需要详细知道每个模块的细节，然后仔细的安排模块的使用。

另一种比较新奇的设计思路是有一定的互联网思维的，尽可能的让模块自己来决定自己的事情。尽可能的去中心化。模块的依赖通过模块的连接来决定。这样的模块有统一的接口和格式。可以直接采用linux的open max， 或者自定义一套模块接口，模块中有端口。通过端口把模块连接起来。又把模块挂在总线上。每一个条端口的连接就是一个流，又把这些流用pipeline 来管理。

每启动一个camera 就创建一个camera的会话，有这个会话来管理这个camera的一切事物。对于每一个会话，模块是共享的，是camera的硬件资源，或其他资源，比如facedetec等算法资源。

那么如何定义模块的结构呢。

1 端口 ，端口属于模块，如果这个模块有只有 src 端口，那么这个模块就是src 模块，只有sink 端口，就是sink模块，否则就是中间模块。没有端口的模块不能连接到流中，但可以完成一些其他的功能，比如接收引擎的设置，报告事件到bus等。连接到流中的端口，也就是说流事件（set get）主要通过port来处理。而来自于引擎的（get set）通过模块来处理，当然port也可以把事件交给module来处理，模块内部的端口可以通过模块来建立关系，也可以建立内部连接，端口有关get set process。

2 模块线程，每一个模块可以有一个线程来处理模块的事情。一个线程对应一个队列，线程就是从队列中取出数据处理，然后应答回去。

3 总线回调，当一个模块向总线注册时，总线向其提供一个回调函数，当模块有事件发生时，调用这个函数向 bus 发消息。然后总线把这个消息提交给管道，管道把这消息送着流发下去。

4 模块的get 和 set ， process。

管道的抽象与功能

管道有两段，一段用于读，一段用于写。camera 引擎负责对管道的监控。而会话管理camera 引擎。

原文链接：

http://www.cnblogs.com/soc-linux-driver/p/3682783.html