Kernel module parameters vs /sys/class/… explanation

driverskernel-modulessysfs

I was making (my first) kernel module to play with the gpio pins of my pandaboard and interrupts.

Already "built-in", I noticed you can do (briefly)

cd /sys/class/gpio
echo 138 > export  # a file gpio138 appears    
echo out > gpio138/direction
echo 1 > gpio138/value

to turn some voltage high or low on connector pins.

Similarly on a kernel module you have module parameters and you can do echo 3 > /sys/module/my_module/parameters/delay_seconds for instance

My questions :

  1. What handles /sys/class/gpio ? A kernel module ? a driver ?

  2. Whatever 1. is, is it possible to have more complicated module parameters in a kernel module, with some directory structure ? Like a 'delays' directory containing the params for delays, … /sys/module/my_module/parameters/delays/delay_led1_seconds

  3. Can you have the parameters somewhere else than in the path /sys/module/my_module/parameters/… ? (/sys/class/a_name/… for instance)

  4. How does the gpio thing creates new/deletes files in /sys/class/gpio when you write to [un]export ?

Best Answer

1) What handles /sys/class/gpio ? A kernel module ? a driver ?

It's a kernel interface similar to the /proc directory.

2) is it possible to have more complicated module parameters in a kernel module, with some directory structure ? Like a 'delays' directory containing the params for delays

Yes; some things in /proc and /sys do use directory hierarchies. If you want to modify or expand them, though, you have to modify the kernel.

#3 has a similar answer -- to make changes you need to change the relevant kernel code.

4) How does the gpio thing creates new/deletes files in /sys/class/gpio when you write to [un]export ?

These are not files on disk, they're just system interfaces.1 When you go to read data from a procfs or sysfs file, what you are really doing is making a request for information from the kernel. The data is then formatted and returned. It probably isn't stored anywhere in the form you see it, although parts of it may be stored in the kernel.

When you write to such a file -- not all of them allow this -- you're sending a request to the kernel to do something specific. This can include, e.g., activating or expanding the GPIO interface.

1. read and write calls are always system calls anyway, since normal files are normally on disk, and the kernel is needed to access hardware. Hence using a filesystem style API here is natural; even if they are not "real files", accessing whatever resource they represent must involve system calls.

Related Question