2013-08-23 76 views
0

我正在学习有关的驱动程序和寻找到其中一些价值被写入/sys/devices/virtual/wdc_per看门狗驱动程序代码,现在我想是这样的逻辑驱动器如何得到来自用户空间的价值和暴露的文件在用户空间是如何回调从用户空间保持到内核空间

"sys/devices/virtual/wdc_per" 

但现在实际上是如何从wdc_per该值达到驱动程序,必须有一定的回调保持

在我的情况下,其基于GPIO看门狗驱动器和gpio_wdt.c可能有这个回调。

但我真的无法弄清楚它是如何实际发生

任何人都可以帮我找到这个用户空间到内核空间的链接。

+0

如果这个代码很大,你能分享我们代码的链接吗?只需检查是否有ioctl系统调用,它们通常会将执行从用户转移到内核空间。 –

回答

1

首先,该驱动程序,gpio_wdt.c,似乎并不在主线内核,因为这日期的存在,所以很难评论它。

SYSFS(通常安装在/sys)实际上是非常容易使用。 This是如何创建Sysfs属性的一个很好的例子。基本上,你创建的属性(将成为SYSFS文件名),并定义了两个操作(回调)注册它们:显示,这是RESP的等价物。 写入读取显示每次读取Sysfs文件(属性)时会调用回调,写入时会调用存储

在编写属于现有类(最有可能的情况而定)的设备驱动程序,你很少需要自己做。这是因为标准的Linux设备类已经有一组Sysfs属性,您的驱动程序将间接使用或多或少的内容。

例如,您可以在/sys/class/leds中找到设备的leds类(LED设备)对每个LED具有一堆Sysfs属性,以便用户可以从用户空间读取/修改它们(亮度,最大亮度,触发器等)。现在,如果您查看/drivers/leds中的LED特定驱动程序,则无法找到手动Sysfs属性创建。但是,当驱动程序被探测时,您会发现调用led_classdev_register,这需要struct led_classdev*作为参数。该结构具有特定驱动程序需要提供的brightness_set回调成员。当用户写入/sys/class/leds/whatever-led/brightnessleds类的 SYSFS回调函数被调用依次调用特定的驱动程序的brightness_set回调。

我的观点是:确保您在手动添加Sysfs属性之前真的知道您的设备类。无论如何,在将您的驱动程序提交给LKML时,如果这是一个很好的决定,您将足够快地知道。

相关问题