I am learning about the driver and looking into the watchdog driver code where some value is being written to /sys/devices/virtual/wdc_per
now I guess this is the logic how driver gets its value from userspace and exposed file in user space is
"sys/devices/virtual/wdc_per"
But now how actually this value from wdc_per is reached to driver, there must some callback maintained
In My case its GPIO based Watchdog driver and gpio_wdt.c may be having this callback.
But I really could not figure out how it actually happens
Anybody can help me find out this userspace to kernel space link.
First of all, this driver,
gpio_wdt.c
, doesn't seem to exist in the mainline kernel as of this date, so it's hard to comment it.Sysfs (usually mounted at
/sys
) is actually very easy to use. This is a great example of how to create Sysfs attributes. Basically, you create attributes (will become the Sysfs file names) and register them with two defined operations (callbacks): store and show, which are the equivalent of resp. write and read. The show callback is called everytime the Sysfs file (attribute) is read and store when it's written.When writing a device driver that belongs to an existing class (most likely your situation), you will rarely need to do that yourself. This is because the standard Linux device classes already have a working set of Sysfs attributes that your driver will use more or less indirectly.
For example, the
leds
class (LED devices), of which you will find the devices in/sys/class/leds
, has a bunch of Sysfs attributes per LED so that a user may read/modify them from userspace (brightness, maximum brightness, trigger, etc.). Now, if you look at LED specific drivers in/drivers/leds
, you won't find manual Sysfs attributes creations. You will find, however, a call toled_classdev_register
when the driver is probed, which takes astruct led_classdev*
as a parameter. This structure has abrightness_set
callback member the specific driver needs to provide. When a user writes to/sys/class/leds/whatever-led/brightness
, theleds
class' store Sysfs callback gets called which in turn calls the specific driver'sbrightness_set
callback.My point is: make sure you really know your device class before manually adding Sysfs attributes. Anyway, when submitting your driver to the LKML, you will know fast enough if it was a good decision.