第二章：资源管理器框架——核心数据结构、消息处理循环、路径空间注册

好，咱们进入正题。资源管理器这东西，说白了就是QNX系统里负责“伺候”某个资源的守护进程。你想想看，一个文件系统、一个串口驱动、甚至一个自定义的硬件设备，在QNX里都是以资源管理器的形式存在的。这一章，我就带你拆开它的骨架，看看里面到底是怎么转起来的。

2.1 核心数据结构：iofunc_attr_t 与 resmgr_attr_t

每个资源管理器，都得有两个“身份证”。一个是描述资源本身属性的，另一个是描述管理器行为属性的。我个人习惯把前者叫“资源属性块”，后者叫“管理器属性块”。

2.1.1 资源属性块：iofunc_attr_t

这个结构体，你几乎在每个资源管理器里都会见到。它定义了资源在路径空间中的“长相”——是文件？是设备？权限怎么设？

#include <sys/iofunc.h>

iofunc_attr_t attr;
iofunc_attr_init(&attr, S_IFCHR | 0666, NULL, NULL);

这里 S_IFCHR 表示这是一个字符设备。如果你做的是块设备，就用 S_IFBLK。权限 0666 表示所有人可读写。嗯，这里要注意：生产环境别这么干，权限要收紧。

我在项目中遇到过一个问题：某个设备驱动，初始化时忘了设置 S_IFCHR，结果客户端打开设备时，返回的是“不是一个设备”的错误。排查了半天，最后发现是属性块没初始化对。所以，初始化属性块时，类型标志位一定要写清楚。

2.1.2 管理器属性块：resmgr_attr_t

这个结构体控制的是管理器本身的行为。比如：最大并发连接数、消息队列深度、是否支持非阻塞I/O等等。

#include <sys/resmgr.h>

resmgr_attr_t mgr_attr;
memset(&mgr_attr, 0, sizeof(mgr_attr));
mgr_attr.nparts = 1;
mgr_attr.msg_max_size = 2048;

这里 nparts 表示I/O向量数，一般设1就够了。msg_max_size 是消息体最大字节数。如果你处理的数据包比较大，记得调大这个值。我曾经有个同事，没改这个默认值，结果客户端发了个4KB的写请求，直接被截断了，数据丢了半截。嗯，血的教训。

2.2 消息处理循环：dispatch 与 resmgr_attach

资源管理器启动后，就进入一个无限循环，等着客户端发消息过来。这个循环，就是消息处理循环。QNX 提供了一个非常优雅的框架——dispatch 层。

2.2.1 创建 dispatch 结构

dispatch_t *dpp = dispatch_create();
if (dpp == NULL) {
    perror("dispatch_create failed");
    exit(EXIT_FAILURE);
}

dispatch_create() 会创建一个调度上下文。这个上下文会管理所有注册进来的通道（channel）、连接（connection）和定时器。说白了，它就是整个消息循环的“心脏”。

2.2.2 注册路径空间

资源管理器要提供服务，得先在路径空间里占个位置。比如你想让客户端通过 /dev/mydevice 访问你的设备，那就得把这个路径注册上去。

resmgr_connect_funcs_t connect_funcs;
resmgr_io_funcs_t io_funcs;
iofunc_funcs_init(RESMGR_PRIV_INFO_VER, &connect_funcs, &io_funcs);

int id = resmgr_attach(dpp, &mgr_attr, "/dev/mydevice",
                       _FTYPE_ANY, 0,
                       &connect_funcs, &io_funcs, &attr);
if (id == -1) {
    perror("resmgr_attach failed");
    exit(EXIT_FAILURE);
}

这里 resmgr_attach 做了几件事：

• 在路径空间注册 /dev/mydevice
• 把连接函数表 connect_funcs 和 I/O 函数表 io_funcs 绑定到这个路径上
• 返回一个 ID，后续可以用来卸载这个路径

你想想看，路径空间就像一个大目录树，每个资源管理器都在上面挂一个节点。客户端 open 这个路径时，QNX 内核会根据路径找到对应的管理器，然后把消息转发过来。

2.2.3 进入消息循环

while (1) {
    int rc = dispatch_block(dpp);
    if (rc == -1) {
        perror("dispatch_block failed");
        break;
    }
    dispatch_handler(dpp);
}

这个循环很简单：阻塞等待消息，然后处理。但背后的事情可不简单。dispatch_block 内部会调用 MsgReceive 接收消息，然后根据消息类型，自动调用你注册的对应函数。比如客户端发了个 read 请求，框架就会调用你注册的 io_read 回调。

我个人习惯在循环里加一个退出标志，方便调试时优雅关闭：

volatile int running = 1;
while (running) {
    int rc = dispatch_block(dpp);
    if (rc == -1) break;
    dispatch_handler(dpp);
}

这样，在信号处理函数里把 running 置0，就能安全退出了。

2.3 路径空间注册的细节与陷阱

路径空间注册，看似简单，但有几个坑。我一个个说。

2.3.1 路径冲突

如果你注册的路径已经被别的管理器占用了，resmgr_attach 会返回 -1，并设置 errno 为 EEXIST。所以，注册后一定要检查返回值。我曾经见过一个项目，代码里没检查返回值，结果两个驱动抢同一个路径，系统启动后谁都用不了。

2.3.2 路径前缀匹配

QNX 的路径空间支持前缀匹配。比如你注册了 /dev，那么客户端 open /dev/mydevice 时，也会匹配到你。但要注意，如果有多个管理器注册了相同前缀，内核会按“最长匹配”原则选择。也就是说，/dev/mydevice 比 /dev 更优先。

2.3.3 动态路径注册与卸载

有些场景下，设备是热插拔的。这时候需要动态注册和卸载路径。卸载用 resmgr_detach：

resmgr_detach(dpp, id, 0);

注意，卸载后，所有已经打开的客户端连接并不会立即断开。它们会继续使用已经分配的资源，直到关闭文件描述符。这是 QNX 的一个设计哲学：先断路径，再等客户端自己退出。

2.4 完整的最小框架示例

说了这么多，咱们拼一个最小的资源管理器框架。它什么都不做，只是注册一个路径，然后进入消息循环。

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/iofunc.h>
#include <sys/resmgr.h>
#include <sys/dispatch.h>

int main(int argc, char *argv[]) {
    dispatch_t *dpp;
    resmgr_attr_t mgr_attr;
    io_funcs_t io_funcs;
    connect_funcs_t connect_funcs;
    io_func_attr_t attr;

    // 1. 创建 dispatch
    dpp = dispatch_create();
    if (dpp == NULL) {
        perror("dispatch_create");
        return EXIT_FAILURE;
    }

    // 2. 初始化属性
    memset(&mgr_attr, 0, sizeof(mgr_attr));
    mgr_attr.nparts = 1;
    mgr_attr.msg_max_size = 2048;

    io_func_attr_init(&attr, S_IFCHR | 0666, NULL, NULL);
    io_func_funcs_init(RESMGR_PRIV_INFO_VER, &connect_funcs, &io_funcs);

    // 3. 注册路径
    int id = resmgr_attach(dpp, &mgr_attr, "/dev/mydevice",
                           _FTYPE_ANY, 0,
                           &connect_funcs, &io_funcs, &attr);
    if (id == -1) {
        perror("resmgr_attach");
        return EXIT_FAILURE;
    }

    printf("Resource manager started at /dev/mydevice\n");

    // 4. 消息循环
    while (1) {
        int rc = dispatch_block(dpp);
        if (rc == -1) break;
        dispatch_handler(dpp);
    }

    // 5. 清理
    resmgr_detach(dpp, id, 0);
    dispatch_destroy(dpp);
    return EXIT_SUCCESS;
}

这个框架虽然简单，但五脏俱全。你可以在 io_funcs 里注册自己的读写回调，就能变成一个真正的设备驱动了。

2.5 本章小结

这一章，我们拆解了资源管理器的三个核心部分：

• 核心数据结构：iofunc_attr_t 和 resmgr_attr_t，一个管资源长相，一个管管理器行为。
• 消息处理循环：通过 dispatch_create、resmgr_attach、dispatch_block 构建无限循环。
• 路径空间注册：注意冲突检测、前缀匹配、动态卸载等细节。

下一章，我们会深入 I/O 函数表的实现，看看客户端发来的 read/write 请求，到底是怎么被处理的。到时候，我会分享一个我踩过的坑——关于 io_read 返回值的一个微妙问题。嗯，到时候细说。