I have a hard time understanding the exact usage of MODULE_DEVICE_TABLE(usb, id_table)
AFAIK this will generate the map files that will be used later by modprobe whenever a new device is inserted, it will match it against those map files and load the module if it matches.
But my misunderstanding is "isn't the module loaded anyway?"
I mean I already loaded it when I did insmod module-name. or am I missing something?
It is usually used to support hot-plugging, by loading/inserting the driver for a device if not already loaded.
There is a similar question here: Detect the presence of a device when it's hot plugged in Linux
(From my ans)
It works as follows:
Each driver in the code exposes its vendor/device id using:
MODULE_DEVICE_TABLE(of, omap_mcspi_of_match);
At compilation time the build process extracts this infomation from all the drivers and prepares a device table.
When you insert the device, the device table is referred by the kernel and if an entry is found matching the device/vendor id of the added device, then its module is loaded and initialized.
According to Linux Device Drivers:
MODULE_DEVICE_TABLE is used to generate map files by depmod program;
When device is hot-plugged, bus driver generates hotplug event. Kernel calls /sbin/hotplug with appropriate environmental variables set;
Given map files and information from environment, /sbin/hotplug decides which module to load and actually loads it. If the module is already loaded, it's OK.
I should mention again that this mechanism just ensures that needed module is in-place when device is plugged. That doesn't link module with that device or anything else. Just loads module.
To check if driver is OK for specific device, match() function from bus_type is used.
Here is how I understands the things [Xbuntu 14.04 compatible].
Once we wrote a module, we can either load it manually, or automatically.
Manually -> insmod modulename.ko or modprob modulename.ko
Automatically-> There are multiple ways.
copy to /lib/modules/`uname -r`/kernel/modulename.ko and update /etc/modules. System will load the module while booting.
Write a script/command to load the module.ko for an specific harware add/change/remove event in a udev rule /etc/udev/rules.d/10-local.rules. You can do both load/unload using this method.
Code your module with MODULE_DEVICE_TABLE registration. Then load your modulename.ko once and run depmod command [sudo depmod -a] to add the new module to /lib/modules/3.16.0-34-generic/modules.alias /lib/modules/3.16.0-34-generic/modules.dep files. As I know, system will load only if the module is not loaded.
You can monitor module loading/unloading using udev events using :
udevadm monitor
command.
Related
I have a simple loadable kernel module which controls an LED by providing blinkingPeriod, on/off features etc...
The device is present at /sys/led , and functions fine.
I have provided an input paramater for the command line which takes in which GPIO the LED is connnected to.
Now I want to reuse the same kernel module, for an additional number of LED's, however I cannot load the module with insmod for additional LED's with a different command line parameter, since an error is thrown:
Error: could not insert module - File exists.
I know this is telling me that I cannot load the same module twice, but what is the best approach when trying to provide LKM's for multiple devices ?
The only solution I can think of is to re-write a LKM for each individual LED/device which hardly seems efficient, or pack all of the LED's in one LKM which isn't very scalable/portable.
Does anyone have any comments on the best approach.
Thanks in advance.
What you should do is:
- adding support for multiple LEDs in your module
- stop using the module parameters to configure the GPIO
- implement a sysfs interface to allow instantiating LEDs. I would use something like gpiolib.
An even better solution would be to use device tree if your platform supports it.
However, your driver is probably not needed and you can surely already do want you want with the leds-gpio and leds-pwm drivers.
What's the difference between loadable modules and built-in (statically linked) modules?
I got this question while finding out an answer for difference between system calls subsys_initcall() and module_init()
Linux kernel supports inserting of modules (aka device drivers) in two ways:
Built-in kernel modules - When the kernel is booted up, the kernel automatically inserts this driver in to the kernel (it's more like it is already part of the kernel code).
Loadable kernel module (LKM) - A driver that is not automatically loaded by the kernel, the user can insert this module at run-time by insmod driver.ko or modprobe driver.ko
The advantage the loadable modules have over the built-in modules is that you can load unload them on run-time. This is good if you are working on a module and you need to test it. Every time you test it and you need to make changes to it, you can easily unload it (rmmod driver.ko or modprobe -r driver.ko) and then after making changes, you can insert it back. But for the built-in modules if you need to make any changes in the module then you need to compile the whole kernel and then reboot the system with the new image of the kernel.
Configuration:
You can configure a module to be either of the two by editing the .config file in the root folder of your kernel source:
DRIVER_1=y // y indicate a builtin module
DRIVER_1=m //m inicates a loadable module
Note: lsmod displays only the dynamically loaded modules not the built-in ones.
Read on: http://www.tldp.org/HOWTO/Module-HOWTO/x73.html
My embedded box doesn't support modeprobe because of security issue. I am trying to do an insmod of the kernel modules. The code I am using lttng. I see that lttng does the kernel object insertion using modeprobe. For my case, I have disabled those modeprobe and I am doing an insmod for it. I am suspecting that because I am doing insmod the sys interface is not created. On the other hand, the modeprobe part I am assuming that it is creating a sys interface. Is it true that modeprobe creates a sysfile interface? If it is true, then what can I do here as I am using insmod.
Actually modprobe is just like 'insmod' except that modprobe resolves module dependencies and finally invokes init_module system call to insert the module. So, in both the cases (modprobe and insmode) init_module() system call is invoked which actually creates sysfs entry for the module.
In lttng case I think there are a lot of modules that needs to be loaded, and there may be dependencies among them, inserting modules one by one using insmod will be very difficult task, first of all you need to find which module depends on what and you have to insert the modules accordingly.
So better thing is use the modprobe or just use the lttng on another machine where you have the modprobe and note the order of the modules and write a script to insert them all.
I compiled the linux kernel with serial device driver statically i.e obj-y.
Now I'm working on a simple serial driver and I want to test it, but since the module is loaded when the kernel boots up, the IO port regions (0x3f8 and onwards) are registered to the serial module. I need to remove(unregister) it so that I can allocate it to my driver.
So, is there any way to remove the statically linked device driver ? or should I recompile the whole kernel :/
You should recompile the whole kernel and make this driver an obj-m.
Once it's loaded (either done automatically by modprobe or manually with insmod), you may remove it (using rmmod), modify the code, compile it again and load it again.
Of course, if there was some critical error that was not handled properly during the driver's operation, the whole kernel will be in an unstable state and you will have to reboot (until you fix what causes this).
I want to compile a device driver in kernel, and I configure it with *, (not in module ). After the compilation, I can't see the device in /proc/device. Also I check the output of make bzImage, the driver has been compiled. Do I need to delete the two lines:
module_init(mydriver_init);
module_exit(mydriver_exit);
There is not enough information to understand your problem. You should show some code.
Anyway, /proc/devices does not show all kernel module. It shows devices, maybe your driver is not registering a device.
You can put some printk() in your code and read it with the command dmesg from your terminal. If your read your print, your module is loaded.
Evan if you do not compile a module as module, but you built it within the kernel, functions
module_init(mydriver_init);
module_exit(mydriver_exit);
must be there. mydriver_init will be executed when the kernel load your driver, module_exit will be executed when the kernel unload your driver.
The /proc/devices file which is read-only doesn't seem to be editable or viewable using editors like VIM. So try 'cat /proc/devices', your device may show up then.