Passing parameters to Linux Device Drivers - builtin, modules

-
In C Programs, we pass command line parameters through argc/argv. Kernel programming also allows us to pass command line parameters.

The command line parameters provides a single linux driver to do multiple things, for example

  • instead of fixing to a single I/O address for read/write, it can provide that as command line argument and allow user to read/write any address. 
  • Enable/disable debug logs/printk
  • Allow user to set the mode if the driver supports multiple modes
How to pass Parameters to modules?

We can add parameters using module_param macro. Declared in moduleparam.h file


name: name of the variable
type: Type of the Variable. Supported types are charp, bool, invbool, int, long, short, uint, ulong, ushort
perm: Permissions for the sysfs entry.  
E.g. S_IRUGO : Only read by all users
       0 : No sysfs entry
You can also use numeric values like 0644 for permission entry.

Sample Program to demonstrate parameter passing


#include <linux/kernel.h>
#include <linux/module.h>

MODULE_LICENSE("GPL");
char *name = "Embedded";
int loop_count = 1;
module_param(name, charp, S_IRUGO);
module_param(loop_count, int, S_IRUGO);

static int test_arguments_init(void)
{
    int i;
    printk(KERN_INFO"%s: In init\n", __func__);
    printk(KERN_INFO"%s: Loop Count:%d\n", __func__, loop_count);
    for (i = 0; i < loop_count; i++) 
        printk(KERN_INFO"%s: Hi %s\n", __func__, name);
    return 0;
}

static void test_arguments_exit(void)
{
    printk(KERN_INFO"%s: In exit\n", __func__);
}

module_init(test_arguments_init);
module_exit(test_arguments_exit);


How to pass Parameters?

Let's find out what will happen when we pass wrong parameters, if I pass string in loop_count.

It will throw invalid parameter error, and the module is not loaded.


How to find out the values of already loaded modules

$ cat /sys/modules/<module_name>/parameters/<parameter_name>


This is only possible, if the permission field in the module_param macro is not zero.

How can we pass arguments to modules which are builtin?

Module parameters for builtin modules are passed through kernel command line. 
Syntax: <module_name>.<parameter_name>=value

So, if the argument module was builtin, we can append argument.loop_count=5 to the kernel command line for passing 5 as loop_count

How can we pass arguments which are called by modprobe?

modprobe reads /etc/modprobe.conf file for parameters.



Comments

Post a Comment

Popular posts from this blog

bb.utils.contains yocto

-
Image
bb.utils.contains  is most commonly used function in Yocto. grep in poky directory returned with 696 count. $ grep -nr 'bb.utils.contains' poky/ | wc -l 696 It's definition is present in 'poky/bitbake/lib/bb/utils.py' file This function returns third argument if the second argument is subset of the first argument else returns fourth argument Let's take an example to understand this. You can see from the above screenshot, when the second argument is a subset of first argument, "present" was returned, else "notpresent" was returned We can also use bb.utils.contains inside if loop. This we can use inside a recipe. if ${@bb.utils.contains('SOMEFLAG','NEWVALUE3','true','false',d)}; then     FOO = 'HELLO' fi
Read more

Difference between RDEPENDS and DEPENDS in Yocto

-
We normally observe these two (RDEPENDS and DEPENDS) whenever we open any recipe. What should we choose when we write our own recipe. DEPENDS -> Build Time Dependency RDEPENDS -> Run Time Dependency DEPENDS: When a recipe 'A' is DEPENDS on recipe 'B'. In this case, Bitbake first builds recipe 'B' and then recipe 'A' E.g. You need 'dbus' to be built before 'wpa_supplicant'. RDEPENDS: When a recipe 'A' is RDEPENDS on recipe 'B'. In this case, Bitbake deploys 'B' on the target system when it deploys 'A'.  E.g. 'perf' RDEPENDS on 'bash' In other words, DEPENDS are those set of packages that should be available while building package, whereas RDEPENDS are set of packages that should be available during execution of the program.
Read more

make config vs oldconfig vs defconfig vs menuconfig vs savedefconfig

-
Image
Building the Linux Kernel is a two-step process: Configuring the Kernel options Building the Kernel with those options. There are many methods available for configuring the kernel. make config: Text-based Configuration.  Options are prompted one after another. All options need to be answered Access to former options is not possible make menuconfig: Menu-driven user interface Allows to navigate forwards and backward directly between features Allows to load and save files with filenames different from ".config" Provides search feature It uses ncurses library for GUI. If the ncurses library is not installed, make menuconfig option fails. To install ncurses library on Ubuntu: sudo apt-get install libncurses5-dev make defconfig: Creates a ".config" file with default options from the ARCH supplied defconfig Configurations are generally stored in the directory: arch/$(ARCH)/configs $ ls arch/x86/configs/ i386_defconfi
Read more