我正在了解驱动程序并查看看门狗驱动程序代码，其中一些值被写入/sys/devices/virtual/wdc_per 现在我猜这是驱动程序如何从用户空间获取其值和用户空间中公开文件的逻辑
"sys/devices/virtual/wdc_per"
但是现在这个来自 wdc_per 的值实际上是如何到达驱动程序的，必须维护一些回调
在我的例子中，它基于 GPIO 的 Watchdog 驱动程序和 gpio_wdt.c 可能有这个回调。
但我真的不知道它是如何发生的
任何人都可以帮我找出这个用户空间到内核空间的链接。
【问题讨论】：
标签： c linux-device-driver watchdog gpio
首先，这个驱动程序gpio_wdt.c，截至目前似乎不存在于主线内核中，所以很难评论它。
Sysfs（通常安装在/sys）实际上非常易于使用。 This 是如何创建 Sysfs 属性的一个很好的例子。基本上，您创建属性（将成为 Sysfs 文件名）并使用两个定义的操作（回调）注册它们：store 和 show，它们相当于 resp。 写和读。每次读取 Sysfs 文件（属性）时调用 show 回调，并在写入时调用 store。
在编写属于现有类的设备驱动程序时（很可能是您的情况），您很少需要自己这样做。这是因为标准 Linux 设备类已经具有一组工作的 Sysfs 属性，您的驱动程序或多或少会间接使用这些属性。
例如，leds 类（LED 设备），您可以在 /sys/class/leds 中找到其中的设备，每个 LED 都有一堆 Sysfs 属性，以便用户可以从用户空间读取/修改它们（亮度、最大亮度、触发等）。现在，如果您查看/drivers/leds 中的 LED 特定驱动程序，您将找不到手动 Sysfs 属性创建。但是，当探测驱动程序时，您会发现对led_classdev_register 的调用，它以struct led_classdev* 作为参数。此结构有一个brightness_set 回调成员，特定驱动程序需要提供。当用户写入/sys/class/leds/whatever-led/brightness 时，leds 类的 store Sysfs 回调被调用，进而调用特定驱动程序的 brightness_set 回调。
我的意思是：在手动添加 Sysfs 属性之前，请确保您确实了解您的设备类别。无论如何，在将您的驱动程序提交给 LKML 时，您会很快知道这是一个好的决定。
【讨论】：