10 设备tx_complete和rx_indicate回调传参问题

发布于 2024-03-21 13:00:08 浏览：932 订阅该版

tx_complete和rx_indicate这两个回调函数中，传入的参数是由设备驱动框架本身控制的，无法传入额外参数。而这两个回调的目的基本上都是用于IPC的，但是当我们希望通过这两个回调来进行IPC时，可能会遇到一些问题。

举个例子，串口阻塞接收，主线程阻塞等待一个信号量，串口rx_indicate回调释放该信号量，这个逻辑很简单。

现在我们增加几个串口，那么这种情况要怎么处理呢？最简单的方法是每个串口开一个线程，每个线程阻塞等待各自的信号量。那么代价是什么呢？并发性能低下，同时浪费资源。

那么有没有更好的方法呢？有。我们可以只用一个线程来处理，怎么做呢？很简单，复用rx_indicate就行了。

在rx_indicate中，我们释放一个信号，主线程等待这个信号，主线程获得信号时，遍历所有串口，把有数据的串口读取出来进行处理。但是这样做不符合我们朴素的逻辑，我们朴素的逻辑是谁有数据处理谁，不要干多余的事，遍历所有串口显然就是多余的事。那么还有没有更好的方法呢？有。

我们可以在rx_indicate中，将串口设备对象放入到一个ready list中，主线程获得信号量后依次从ready list中获取串口设备对象，并读取数据进行处理。这样我们就实现了高性能的同时，占用更少的资源。但问题来了，想要在rx_indicate中实现将串口设备对象放入ready list中，我们需要传入额外的参数才可以做到。

有人说很简单，设备对象都有user_data，可以拿来用，但问题时，这个user_data真的是user可以用的data吗？也许串口设备的user_data可以直接用，那换另一个设备对象呢？框架以及驱动对这个成员的使用完全没有任何规范，有些内部直接用了，有些还预留着，这个user_data能不能拿来传递参数，完全依赖设备框架以及设备驱动的内部实现，假如我要实现一个特定的功能，或者我的应用明确绑定特定的设备对象，那是可以去查看内部实现来决定的，但问题是，假如我要实现一个通用框架，那就不能如此假定了，这个时候，rx_indicate以及tx_complete已经不能满足要求了。

这就是我现在遇到的问题，我在实现一个支持多实例的特定通讯协议的通用框架，后端对接的设备是不做要求的，这种情况我要怎么做呢？

我不明白设计之初为什么要这样做，不允许额外传参有什么好处吗？为了安全吗？问题是作为一个系统组件，职责是提供接口，至于如何选择，那是用户的事情。

-----
可能不上伪码大家不太方便理解，我现在写个简单的伪码

```
struct demo
{
	rt_device_t device;
	void *member_a;
	void *member_b;
	...
};

static rt_err_t rx_ind(rt_device_t dev, rt_size_t size)
{
	// 这里我们希望的逻辑操作某个demo对象中的member_a成员
	// 传入的dev是这个demo对象中的device成员
}

rt_err_t demo_init(struct demo *demo, const char *dev_name)
{
	demo->device = rt_device_find(dev_name);
	
	/* 初始化其他成员以及其他的一些操作 */
	...
	...
	rt_device_open(demo->device, oflag);
	
	rt_device_set_rx_indicate(demo->device, rx_ind);
	
	return RT_EOK;
}

int main(void)
{
	struct demo demo1, demo2, demo3, demo4;
	
	demo_init(&demo1, "uart1");
	demo_init(&demo2, "uart2");
	demo_init(&demo3, "uart3");
	demo_init(&demo4, "uart4");
	
	while (1);
}
```

在上面这个场景中，请问rx_ind应该怎么做？假如现在这个场景是明确某个应用场景的可以在rx_ind里面依次判断，那我每加一个demo就改一次rx_ind吗？假如demo是一个框架呢？框架实现者是没有那么多上下文的，谁知道用户会在main里面初始化多少个demo呢？