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

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《为什么我的 Go 应用程序不像 busybox `cat` 命令那样从 sysfs 读取数据？》，聊聊，我们一起来看看吧！

在 linux 4.19.93 armv6l 上运行 1.12。 硬件是运行 yocto linux 映像的 raspberypi 0 w (bcm2835)。

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

它在 sysfs 和 busybox shell 上运行得很好。

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

我之前曾将 go 与 iio 设备一起使用，这些设备在此硬件平台上支持高采样率的触发器和缓冲输出。但是，对于此应用程序，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] 之间的符文）——这是我所期望的。

旁白：我预计这与文件轮询和 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。恶心。

解决方案

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

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

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

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

我确信今晚我已经看这个太久了，这个代码可能很糟糕。也就是说，这是我想出的代码片段，它与 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 读取数据？》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！