loading driver with modeprobe or insmod with parameters

[gharig]

Hello,

So I'm trying to figure out why parameters being passed while loading a kernel module using modprobe or insmod  are not working as to the way I believe they should work.

Code: [Select]

sudo modprobe someDriver Param1=123 Param2=456 OR

Code: [Select]

sudo insmod ./someDriver.ko Param1=123 Param2=456
The driver assigns default value for Param1 = 0 and Param2 = 1

The driver prints out the values Param1 = 0 and Param2 = 1 in dmesg
What I expect is that Param1 = 123 and Param2 = 456

Is the busybox version of modprobe the issue?
Maybe there is some small detail that I'm overlooking.

Thanks
gharig


I mentioned this earlier in another post too.
http://forum.tinycorelinux.net/index.php/topic,24005.msg151255.html#msg151255

[Rich]

Hi gharig
Based on your other post, it sounds like like you are not reading the values being passed to your module.

[gharig]

Hi Rich,

My understanding is that the macro module_param( variable_name, type, permission ) handles this when the kernel module is loaded.


this is for a very simple kernel module

Code: [Select]


//.......
static int Param1= 0;
static int Param2 = 1;

module_param( Param1, int, 0 );
module_param( Param2, int, 0 );

//.........


static int __init test_init(void)
{
 
        printk(KERN_INFO "Param1 = %d  \n", Param1);
        printk(KERN_INFO "Param2 = %d  \n", Param2);
        printk(KERN_INFO "Kernel Module Loaded Successfully...\n");
    return 0;
}

static void __exit test_exit(void)
{
    printk(KERN_INFO "Kernel Module Removed Successfully...\n");
}

module_init(test_init);
module_exit(test_exit);




So after I make and install the module I can call modprobe with the values I pass in with the parameters.

Code: [Select]

sudo modprobe someDriver Param1=123 Param2=456

So that when I look at dmesg I should see the following

Code: [Select]

Param1=123
Param2=456
Kernel Module Loaded Successfully...

So when you say that I'm not reading the values I'm a bit confused.
Any light you could shed on me would be greatly appreciated.

Thanks
gharig

[Rich]

Hi gharig

My understanding is that the macro module_param( variable_name, type, permission ) handles this  ...

Here you set the variable name and type.

Code: [Select]

module_param( Param1, int, 0 );
module_param( Param2, int, 0 );

For permission you used 0. I think that's your problem. Try it like this:

Code: [Select]

module_param( Param1, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP );
module_param( Param2, int, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP );

[gharig]

Hi Rich,

Sorry to be a pest, but I tried your suggestion for setting the permissions in module_param().
The results are the same.  So I have attached the test.c and the makefile.  Maybe when you get a chance you can see what is wrong.

If you are to see the parameters change on your system then maybe it might be something with my card.

I'm running Tinycore 13 32bit on a Winsystems C412 that has the following:

1 GHz DMP Vortex86DX3 Processor (Dual core) CPU

2 GB DDR3-LV System RAM

Low Power

10 Year Availability

Rugged Design for Demanding Environments

-40°C to +85°C Operating Temperature Range

PC/104-Plus Small Form Factor

Shock and Vibration Tested

Connectivity and I/O for Embedded Systems

Dual Ethernet (1x Fast Ethernet, 1x Gigabit)

4x USB 2.0

24x GPIO 5V with Event Sense

4x Serial Ports (2x RS-232, 2x RS-232/422/485)

Parallel Port LPT

Audio

Graphics Support

Dual video output (VGA, LVDS with digital backlight dimmer)

 


I haven't tried this on my Hyper-V, but I will tonight when I get home, and let you know the results from that system.


As always thanks for your help.
gharig

[Rich]

Hi gharig
What happens if you change this:

Code: [Select]

int Param1, Param2;to this:

Code: [Select]

static int Param1=10;
static int Param2=20;
By the way, parameters should have a default value in case nothing is passed in.

[gharig]

Hi Rich,

Hi finally got home, from another great day at work. I must say that I have to pinch myself from time to time, I get paid to code. Anyway I did as you suggested, I changed the variables to be static, fried up the Hyper-V, ran the development setup compile.tcz and the lot.  Loaded the Tinycore modules.  Modified the code to change the variables to static. 

Code: [Select]


static int Param1=10;
static int Param2=20;


and then ran the following:
then I ran the following:

Code: [Select]


make

sudo make install

sudo modprobe test Param1=345 Param2=759



The param in dmesg values are:
Param1=10
Param2=20

But I'm expecting:
Param1=345
Param2=759

So this is consistant on two seperate systems, the winsystem c412 and my home computer running Tinycore 13 in Hyper-V

Still at a loss.

So I'm curious if you  built the test.c module  from files I attached in an earlier post, and did you end up getting a different result?

Thanks For all your help
gharig

[Rich]

Hi gharig
I setup a build environment under TC10 x86 and tried several examples I found online. I had no luck setting any
parameters when loading any of those examples. I was able to make modifications to parameters through
/sys/module/DRIVERNAME/parameters.  This was confirmed by having the module print the parameters in the
routine listed in  module_exit().

[gharig]

Hi Rich,

Thank you for looking and confirming that you are seeing the exact same problem that I was seeing, I thought I was going crazy.
Yes I can probably do a work around by setting the parameters in /sys/module/DRIVERNAME/parameters and using the module_param_cb() function, and thank for confirming that too, but I would prefer not too if possible.
And for what I'm doing I could also create two different drivers with preassigned values, and just load the driver I want to use. There is no law saying that I can't do that.

So back to my first thought...
Do you think that it could be something in the Busybox tools for modprobe and insmod on how it got built out?  I have not checked yet, but will later this weekend, I'm curious to find out  if the same behavior occurs in the 64bit version. I will report back to you my findings.
Then my last question..., is this something that could be looked at, so that future versions will function the way they are suppose too?

Thanks for all your help. I still consider you to be a true genius....
gharig

[Juanito]

Did you try the module-init-tools extension?

[gharig]

Hi Juanito,

I have not tried the module-init-tools extensions, I'm did not know about this, but I will, and I will let you know my results.

Thanks
gharig

[gharig]

Hi Juanito and Rich,

The suggestion that Juanito made, to install module_init_tools.tcz was just the ticket.
Now the test program that I created reports the correct values.

So when I run

Code: [Select]

sudo insmod ./test.ko Param1=345 Param2=567

In dmesg I see the following.

Code: [Select]

Param1=345
Param2=567

Thank You Very Much For your help.
Case Closed...


Thanks
gharig 

[Rich]

Hi gharig

... Case Closed...

Not so fast. Now that I know the problem wasn't the code, but a problem with the busybox loaders, I decided to
try something. I added the following to  /etc/modprobe.conf:

Code: [Select]

options hello-5 myint=7Then I ran:

Code: [Select]

modprobe hello-5Checking dmesg showed that  myint  had been changed from 1 to 7. So the busybox version of modprobe checks
/etc/modprobe.conf  for options.

[Rich]

Hi gharig
Although I did not try it, passing options as kernel parameters is something else that should work.

According to  Kernel Parameters  found here:
https://mjmwired.net/kernel/Documentation/kernel-parameters.txt

... modprobe looks through the kernel command line (/proc/cmdline) and
collects module parameters when it loads a module ...

Adding this boot code should have the same effect as using  /etc/modprobe.conf:

Code: [Select]

hello-5.myint=7

[curaga]

If there's a bug on busybox's modprobe params on command line, please report it to busybox.

edit: Oh, no bug, but a missing config option.
# CONFIG_FEATURE_CMDLINE_MODULE_OPTIONS is not set