【问题标题】:create /dev/fakeDevice supporting read, write and ioctl创建支持读、写和ioctl的/dev/fakeDevice
【发布时间】:2014-04-17 14:14:32
【问题描述】:

我有一个在嵌入式设备(x86,最近的 linux)上运行的软件。为了简化开发、使用自动化测试等,我想在我的主机系统上运行它。通过对构建系统进行一些调整,代码编译得很好。下一步将是创建“虚拟设备”。

该应用程序不使用任何类型的库,而是通过读、写和 ioctl 调用直接与多个设备通信。这些设备代表具有自定义协议的自定义硬件。要创建一个虚拟环境,我需要响应这个调用。一种可能的方法是:

  • 为每个需要的设备创建设备驱动程序(/dev/deviceA/dev/deviceB/dev/deviceC、...)
  • 创建另一个设备驱动程序以与用户空间通信(例如,/dev/deviceSimulation
  • 所有虚拟设备都会将每个呼叫转发到/dev/deviceSimulation
  • 另一个用户空间应用程序与/dev/deviceSimulation 交互并跟踪模拟的状态。

有没有更简单的方法来做到这一点,而无需通过 linux 内核进行往返?

【问题讨论】:

  • 内核的往返可能是微不足道的。一般来说,这个想法似乎是合理的(除非您想通过程序本身的条件编译来替换 I/O 层)。特别是,最好让内核直接通过,同时将模拟逻辑保留在用户空间中。
  • 我不习惯内核驱动程序开发,我想保持代码库很小。我跳了起来,周围有一个神奇的工具,可以(ab)用于这项任务。在内核空间中做所有事情会更痛苦,我会被限制在 C 和其他几个计划的功能中是不可能的 - 所以是的,这从来都不是一个选项;)
  • 听起来正是我想要的。您是否有指向用户空间部分的某种文档的链接?

标签: linux linux-kernel linux-device-driver


【解决方案1】:

回到这个项目并回答我自己的问题:是的,必须完成内核的往返。但是有一个图书馆在做繁重的工作:CUDA(谢谢,CL)。

文档感觉有点稀缺(或者我看错了地方),并且提供的 cuda 示例充满了其他一些处理参数或缓冲区处理的熔断方式。所以这里是另一个例子(甚至更简化,这里没有任何有用的事情发生......):

设备“驱动程序”(cusetest.c):

#define FUSE_USE_VERSION 30
#define _FILE_OFFSET_BITS 64
#include <fuse/cuse_lowlevel.h>
#include <fuse/fuse_opt.h>

#include <stdio.h>

#define LOG(...) do { fprintf(stderr, __VA_ARGS__); puts(""); } while (0)

static void cusetest_open(fuse_req_t req, struct fuse_file_info *fi) {
    LOG("open");
    fuse_reply_open(req, fi);
}

static void cusetest_read(fuse_req_t req, size_t size, off_t off,
                         struct fuse_file_info *fi) {
    LOG("read");
    fuse_reply_buf(req, "Hello", size > 5 ? 5 : size);
}

static void cusetest_write(fuse_req_t req, const char *buf, size_t size,
                          off_t off, struct fuse_file_info *fi) {
    LOG("write (%u bytes)", size);
    fuse_reply_write(req, size);
}

static void cusetest_ioctl(fuse_req_t req, int cmd, void *arg,
                          struct fuse_file_info *fi, unsigned flags,
                          const void *in_buf, size_t in_bufsz, size_t out_bufsz) {
    LOG("ioctl %d: insize: %u outsize: %u", cmd, in_bufsz, out_bufsz);
    switch (cmd) {
    case 23:
        if (in_bufsz == 0) {
            struct iovec iov = { arg, sizeof(int) };
            fuse_reply_ioctl_retry(req, &iov, 1, NULL, 0);
        } else {
            LOG("  got value: %d", *((int*)in_buf));
            fuse_reply_ioctl(req, 0, NULL, 0);
        }
        break;
    case 42:
        if (out_bufsz == 0) {
            struct iovec iov = { arg, sizeof(int) };
            fuse_reply_ioctl_retry(req, NULL, 0, &iov, 1);
        } else {
            LOG("  write back value");
            int v = 42;
            fuse_reply_ioctl(req, 0, &v, sizeof(int));
        }
        break;
    }
}

static const struct cuse_lowlevel_ops cusetest_clop = {
        .open           = cusetest_open,
        .read           = cusetest_read,
        .write          = cusetest_write,
        .ioctl          = cusetest_ioctl,
};

int main(int argc, char** argv) {
    // -f: run in foreground, -d: debug ouput
    // Compile official example and use -h
    const char* cusearg[] = {"test", "-f", "-d"};
    const char* devarg[]  = {"DEVNAME=cusetest" };
    struct cuse_info ci;
    memset(&ci, 0x00, sizeof(ci));
    ci.flags = CUSE_UNRESTRICTED_IOCTL;
    ci.dev_info_argc=1;
    ci.dev_info_argv = devarg;

    return cuse_lowlevel_main(3, (char**) &cusearg, &ci, &cusetest_clop, NULL);
}

编译运行:gcc -Wall -g -lfuse cusetest.c -o cusetest &amp;&amp; sudo ./cusetest

测试程序(testcusetest.c):

#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
#include <sys/ioctl.h>

int main() {
    int fd = open("/dev/cusetest", O_RDWR);

    const char* msg = "Fooooo";
    write(fd, msg, strlen(msg));

    int v = 63;
    ioctl(fd, 23, &v);
    fprintf(stderr, "value is now: %d\n", v);
    ioctl(fd, 42, &v);
    fprintf(stderr, "value is now: %d\n", v);
    close(fd);
    return 0;
}

编译运行:gcc -Wall testcusetest.c -o testcusetest &amp;&amp; ./testcusetest

还有很多工作要做,但应该足以开始。一个陷阱是CUSE_UNRESTRICTED_IOCTL。如果输入或输出缓冲区的长度为零,您需要回复fuse_reply_ioctl_retry()。将在填充缓冲区的情况下再次调用回调。

【讨论】:

  • 谢谢,很好的问答!
猜你喜欢
  • 1970-01-01
  • 2011-06-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多