时间戳

首页 > 解决方案 > 为什么我的 Go 应用程序没有像 busybox `cat` 命令那样从 sysfs 中读取数据？

go - 为什么我的 Go 应用程序没有像 busybox `cat` 命令那样从 sysfs 中读取数据？

问题描述

继续 1.12 Linux 4.19.93 armv6l。硬件是运行 yocto linux 映像的 raspberypi zero w (BCM2835)。

我有一个由 srf04 linux 驱动程序驱动的 gpio 驱动的 SRF04 接近传感器。

它在 sysfs 和 busybox shell 上工作得很好。

# cat /sys/bus/iio/devices/iio:device0/in_distance_raw
1646

我以前在 IIO 设备上使用过 Go，这些设备在这个硬件平台上支持高采样率的触发器和缓冲输出。然而，对于这个应用程序，srf04 驱动程序没有实现这些 IIO 功能。德拉特。我真的不想自己（此时）为驱动程序添加缓冲区/触发器支持，因为我不需要“高”采样​​率。每秒几次 ping 就足以满足我的目的。我想我会计算平均值和标准。开发。用于数据点的滚动窗口并从噪声中“区分”信号。

因此，我非常乐意使用 Go 从已发布的 sysfs 文件中读取字节。

这让我想到了这篇文章。当我打开文件进行读取并尝试 Read() 任意数量的字节时，我总是会收到一般-EIO错误。

func (s *Srf04) Read() (int, error) {
    samp := make([]byte, 16)

    f, err := os.OpenFile(s.readPath, OS.O_RDONLY, os.ModeDevice)
    if err != nil {
        return 0, err
    }
    defer f.Close()

    n, err := f.Read(samp)
    if err != nil {
        // This block is always executed.
        // The error is never a timeout, and always 'input/output error' (-EIO aka -5)
        log.Fatal(err)
    }
    ...
}

这对我来说似乎是奇怪的行为。所以我决定搞乱使用io.ReadFull. 这产生了不可靠的结果。

func (s *Srf04) Read() (int, error) {
    samp := make([]byte, 16)

    f, err := os.OpenFile(s.readPath, OS.O_RDONLY, os.ModeDevice)
    if err != nil {
        return 0, err
    }
    defer f.Close()

    for {
        n, err := io.ReadFull(readFile, samp)
        log.Println("ReadFull ", n, " bytes.")
        if err == io.EOF {
            break
        }
        if err != nil {
            log.Println(err)
        }
    }

    ...

}

我最终将它添加到一个循环中，因为我发现从“一次性”读取到多个读取调用的行为发生了变化。如果它得到一个 EOF，我让它退出，否则我会反复尝试读取。

结果直接疯狂不可靠，似乎返回随机结果。有时我得到 -5，有时我从设备读取 2 - 5 个字节。有时我在 EOF 之前得到没有 eof 文件的字节。字节似乎代表数字的字符数据（每个符文是 [0-9] 之间的符文） - 这是我所期望的。

旁白：我希望这与文件轮询和阻塞 IO 实现有关，但我无法真正说出。

作为临时解决方法，我决定尝试使用 os.exec，现在我得到了我期望看到的结果。

func (s *Srf04)Read() (int, error) {
    out, err := exec.Command("cat", s.readPath).Output()
    if err != nil  {
       return 0, err
    }
    return strconv.Atoi(string(out))
}

但是伊克。os.exec. 呸。

标签： goraspberry-piembedded-linuxsysfsiio

解决方案

我会尝试在cat whatever下面运行该咒语strace，然后查看read(2)调用cat实际设法执行的操作（包括实际读取的字节数），然后我会尝试在 Go 中重新创建该行为。

我自己对问题原因的猜测是驱动程序（或 sysfs 层）还没有准备好处理某些访问模式。

首先，考虑一下GNUcat不是一个头脑简单的字节铲，而是一个相当棘手的软件，除其他外，它考虑输入和输出设备（如果可用）的最佳 I/O 块大小，调用fadvise(2)等等。当您在 sysfs 导出的文件上运行它时，并没有实际使用其中的任何一个，但它可能会分别影响完整堆栈（从 sysfs 层开始）在使用cat和使用您的代码的情况下的执行方式。

因此我的建议是：从strace-ing the开始cat，然后尝试在你的 Go 代码中重新创建它的使用模式；然后尝试提出其中的一个最小子集，这是可行的；然后深刻地评论你的代码;-)

推荐阅读