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