From the perspective of a user land program, you should think of the driver as a "black box" with well defined interfaces instead of code with variables you want to change. Using this mental model, there are four ways (i.e. interfaces) to communicate control information to the driver that you should consider:
- Command line options. You can pass parameters to a kernel module which are available to it during initialization.
- IOCTLs. This is the traditional way of passing control information to a driver, but this mechanism is a little more cumbersome to use than
sysfs
.
proc
the process information pseudo-file system. proc
creates files in the /proc
directory which user land programs can read and sometimes write. In the past, this interface was appropriated to also communicate with drivers. Although proc
looks similarly to sysfs
, newer drivers (Linux 2.6) should use sysfs
instead as the intent of the proc
is to report on the status of processes.
sysfs
is a pseudo-file system used to export information about drivers and devices. See the documentation in the kernel (Documentation/filesystems/sysfs.txt) for more details and code samples. For your particular case, pay attention to the "store" method.
Depending on when you need to communicate with the driver (i.e. initialization, run time), you should add either a new command line option or a new sysfs
entry to change how the driver treats the value of reserved fields in the packet.
With regard to filp_open
, the function's comment is
/**
* This is the helper to open a file from kernelspace if you really
* have to. But in generally you should not do this, so please move
* along, nothing to see here..
*/
meaning there are better ways than this to do what you want. Also see this SO question for more information on why drivers generally should not open files.