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