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

Question

在 Linux 4.19.93 armv6l 上进行 1.12 .
硬件是运行 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，这些设备在这个硬件平台上支持高采样率的触发器和缓冲输出。但是对于此应用程序 the srf04 driver没有实现那些 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 文件的字节。字节似乎代表数字的字符数据(每个 rune 是 [0-9] 之间的 rune ) - 这是我所期望的。

旁白:我希望这与文件轮询和阻塞 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 .呸。

Answer 1

我会尝试运行 cat whatever strace下的咒语然后看看 read(2)来电cat实际上设法做到了(包括实际读取的字节数)，然后我会尝试在 Go 中重新创建该行为。

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

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

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