为什么我的 Go 应用程序不像 busybox `cat` 命令那样从 sysfs 读取？

Question

在 Linux 4.19.93 armv6l 上使用 1.12。硬件是 raspberypi 零 w (BCM2835) 运行 yocto linux 图像。

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

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

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

我之前使用过 Go 和 IIO 设备，这些设备支持在此硬件平台上以高采样率触发和缓冲输出。但是，对于此应用程序，the srf04 driver 并未实现这些 IIO 功能。糟了。我真的不想自己（此时）为驱动程序添加缓冲区/触发器支持，因为我不需要 'high' 采样率。每秒几次 ping 应该足以满足我的目的。我想我会计算均值和标准差。开发者对于滚动的 window 个数据点和 'divine' 噪声中的信号。

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

这让我想到了这个 post。当我打开文件进行读取并尝试 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)
        }
    }

    ...

}

我最终将它添加到一个循环中，因为我发现行为从 'one-off' 读取更改为一个接一个的多个读取调用。如果它收到 EOF，我会让它退出，并反复尝试阅读其他内容。

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

旁白：我认为这与文件轮询和 go 阻塞 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 块大小输入和输出设备（如果可用），调用 fadvise(2) 等。当您在 sysfs 导出的文件中运行时，并没有实际使用任何一个，但它可能会影响整个堆栈的方式（从 sysfs 层开始）分别在使用 cat 和您的代码的情况下执行。

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

Answer 2

我确定我今晚看这个太久了，这段代码可能很糟糕。也就是说，这是我想出的片段，它与 busybox cat 一样可靠，但在 Go 中。

Srf04 结构包含一些东西，重要的部分包括在下面：

type Srf04 struct {
    readBuf     []byte `json:"-"`
    readFile    *os.File `json:"-"`
    samples     *ring.Ring `json:"-"`
}


func (s *Srf04) Read() (int, error) {
/** Reliable, but really really slow.
    out, err := exec.Command("cat", s.readPath).Output()

    if err != nil {
        log.Fatal(err)
    }

    val, err := strconv.Atoi(string(out[:len(out) - 2]))
    if err == nil {
        s.samples.Value = val
        s.samples = s.samples.Next()
    }
 */
    // Seek should tell us the new offset (0) and no err.
    bytesRead := 0
    _, err := s.readFile.Seek(0, 0)

    // Loop until N > 0 AND err != EOF && err != timeout.
    if err == nil {
        n := 0
        for {
            n, err = s.readFile.Read(s.readBuf)
            bytesRead += n
            if os.IsTimeout(err) {
                // bail out.
                bytesRead = 0
                break
            }
            if err == io.EOF {
                // Success!
                break
            }
            // Any other err means 'keep trying to read.'
        }
    }

    if bytesRead > 0 {
        val, err := strconv.Atoi(string(s.readBuf[:bytesRead-1]))
        if err == nil {
            fmt.Println(val)
            s.samples.Value = val
            s.samples = s.samples.Next()
        }
        return val, err
    }

    return 0, err
}

为什么我的 Go 应用程序不像 busybox `cat` 命令那样从 sysfs 读取？

Why is my Go app not reading from sysfs like the busybox `cat` command?

go

embedded-linux

sysfs

raspberry-pi

iio