一般来说,在ucLinux上,ioctl比写入/ sys文件系统更快吗?

Mik*_*owe 8 linux sysfs

我有一个我正在使用的嵌入式系统,它目前使用sysfs来控制某些功能.

但是,如果可能的话,我们希望加快功能.

我发现这个子系统也支持和ioctl接口,但在重写代码之前,我决定通过搜索来查看哪个是更快的接口(在ucLinux上):sysfs或ioctl.

有没有人能够很好地理解这两种实现方式,让我粗略地了解每种实现的开销差异?我正在寻找通用信息,例如"ioctl更快,因为你已经从函数调用中删除了文件层".或者"它们大致相同,因为sysfs具有非常简单的界面".

2013年10月24日更新:

我目前正在做的具体情况如下:

int fd = open("/sys/power/state",O_WRONLY);
write( fd, "standby", 7 );
close( fd );
Run Code Online (Sandbox Code Playgroud)

在kernel/power/main.c中,处理此写操作的代码如下所示:

static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
               const char *buf, size_t n)
{
#ifdef CONFIG_SUSPEND
    suspend_state_t state = PM_SUSPEND_STANDBY;
    const char * const *s;
#endif
    char *p;
    int len;
    int error = -EINVAL;

    p = memchr(buf, '\n', n);
    len = p ? p - buf : n;

    /* First, check if we are requested to hibernate */
    if (len == 7 && !strncmp(buf, "standby", len)) {
        error = enter_standby();
  goto Exit;
    ((( snip )))
Run Code Online (Sandbox Code Playgroud)

可以通过移动到自定义ioctl()来加速,其中处理ioctl调用的代码类似于:

case SNAPSHOT_STANDBY:
    if (!data->frozen) {
        error = -EPERM;
        break;
    }
    error = enter_standby();
    break;
Run Code Online (Sandbox Code Playgroud)

(因此ioctl()调用与sysfs函数相同的低级函数).

del*_*ver 3

如果 sysfs 指的是sysfs()库调用,请注意以下内容man 2 sysfs

笔记

这个 System-V 派生的系统调用已过时;不要使用它。 在具有 /proc 的系统上,可以通过 /proc/filesystems 获取相同的信息;请改用该接口。

我不记得注意到有ioctl()sysfs 接口的东西,但它们可能存在。无论如何,我会使用 proc 或 sys 句柄,因为这往往不那么神秘并且更灵活。

如果 sysfs 是指访问 中的文件/sys,那么这是首选方法。

我正在寻找通用信息,例如“ioctl 更快,因为您已从函数调用中删除了文件层”。

访问 procfs 或 sysfs 文件不会产生 I/O 瓶颈,因为它们不是真正的文件——它们是内核接口。所以不,通过“文件层”访问这些东西不会影响性能。我认为这是 Linux 系统编程中一个并不罕见的误解。程序员可能会对不好的系统调用、系统调用感到不安,并偏执地认为打开文件会变慢。当然,ABI 中的文件 I/O 无论如何都只是系统调用。导致普通(磁盘)文件读取缓慢的原因不是对打开、读取、写入等的调用,而是硬件瓶颈。

在执行此操作时,我总是使用基于低级描述符的函数(open()read())而不是高级流,因为在某些时候,一些经验使我相信它们对此特别可靠(从 读取/proc)。我不能说这是否绝对正确。