I know how to make loadable kernel modules in Linux.
But i want that loadable kernel module to be a part of the kernel , and after booting that driver should automatically load, like most of the other general driver.
How to do that?
There are two ways to do for your query
1) building your module as statically compiled along with kernel(your source code should reside in kernel tree ),so while building build it static which come as a part of kernel,
so when kernel boots your module will be loaded.
2)Same as above but while building build as dynamic loadable module so that wheneever required you can load it.
to illustrate above concept you can try below link for simple helloworld example.
http://www.agusbj.staff.ugm.ac.id/abjfile/Chap8.pdf
You have to configure modprobe to load automatically driver after kernel boot. Here an example of configuration.
If you want to a built-in module, you must re-compile the kernel, and set Y in the configuration file on all modules that you want inside the kernel
Related
I had an issue with trying to get the wpa_supplicant to run on board running a custom Embedded Linux distribution. After some debugging it turned out that it was because the domain type PF_PACKET was not supported by the kernel:
drv->eapol_tx_sock = socket(PF_PACKET, SOCK_DGRAM, 0);
This is supported by the af_packet module and loading it beforehand fixed the problem. I noticed that it also has the alias "pf-net-17" and it appears that the kernel can load this module at runtime if requested from user-space via the alias. I tested this in another Embedded Linux distribution and sure enough this seems to be the case. It was loaded after the supplicant was called.
Does anyone know why this functionality is not working in the first setup? Maybe I missed a kernel setting?
There are basically 2 reasons why this worked on another system and not on your board:
the PF_PACKET was configured to be built in the kernel or not as a module.
The af_packet module was automatically loaded at runtime, either as a dependancy to another module or as a module to be automatically loaded at boot
I suggest that you read this document about module loading which is quite concise, yet complete and precise.
A way to fix your problem would be to make sure that depmod was run for your target system so that the module dependancy for your build is updated of load the af_packet module automatically at boot.
Another place to look at is udev, which is meant to load modules according to the devices detected by the kernel. Maybe this is also missing/misconfigured in your system.
For an application to be compiled on Linux the steps involved are:
Pre-processing->Compilation->Assembly->Linking.
What are the steps involved in compiling a kernel driver? Are the steps different if I compile the driver as a built-in module vs a module vs using custom Makefile?
Right same steps are followed for device driver in Linux :-
Pre-processing->Compilation->Assembly->Linking.
These are basic steps need to followed every where , no matter how one follow.
Regarding built-in module vs a module vs using custom Makefile :: -
Device drivers can be compiled with whole kernel and device driver is part of kernel image means device driver is statically linked with the kernel. When device driver is statically linked with kernel and its loaded at boot up.
When device driver is compiled as module , then this module is not part of kernel image and can be loaded in system on the fly.
When device driver is part of kernel image , this device driver source files compiled as normal file of kernel source tree.
For example sample.c has device driver code and CONFIG_SAMPLE config macros controlling its compilation then include following line in Makefile
Config-($CONFIG_SAMPLE) = sample.o
When value of config macro is y , the driver gets compiled with kernel image and when its value is n then , then device driver don’t get compiled.
Device drivers as a module can be compiled using following commands.
make -C path/of/kernel path/of/driver/in/kernel/folder/module.ko
For security reasons, the kernel ceased to export characters necessary for writing security modules in the form of loadable kernel modules (Linux Kernel Module, LKM) starting with version 2.6.24.
And you can't export sys_call_table, again for security reasons.
But then, how can I filter filesystem requests?
I'll state it simply: I want to hook the "open" function!
I don't want to have to compile my own version of the kernel, what's the point of drivers? It should work for all kernels.
Please help, thought I would have more freedom than Windows with Linux, but now I see the most precious parts of my life are blocked in Linux.
I've written a kernel module that can do this called tpe-lkm. I've also mentioned it on some other questions similar to this here on StackOverflow:
access to the sys_call_table in kernel 2.6+
Reading kernel memory using a module
intercepting file system system calls
Hope one of these helps you out.
Neaded your help on lirc.
I want to use lirc for decoding of ir signals. I am using a custom board based on Cortex A8 with 2.6.37 kernel and IR is received thru’ serial port. I can see UART interrupts coming properly when I press the button of the IR remote.
But when I try to run the configure script with device=all or device=serial and run make and make install as mentioned in the installation page on lirc.org, It sends me an error that the kernel configuration is invalid.
But still I am able to generate the .ko files(lirc_dev and lirc_serial) needed for loading the kernel modules but not able to insert lirc_serial module as I am using a port having mmio and the port used by lirc is io mapped.
My virtual adddress is 0xfa022000 and physical address is 0x48022000(using ttyO1).
Can I use lirc for this address.
Do I need to make any change in the code?
Also I cannot install directly on the board I am using as I could not build the kernel source code on the board due to minimal things present on the board.So am running the setup on some other machine and cross compiling for arm.
So I could not have the configuration files placed at the right locations also the node(/dev/lirc0) is not made.
Shall I make the node manually or will inserting the modules do the work?
Also do I need to have the configuration files at proper location before inserting the modules?
Also does it have any dependency with the kernel version?
Please suggest me the steps for cross compiling and loading the kernel modules on my own and also let me know which all conf files or other files are required to be present for making the things work.
I would really be very thankful to you for the help.
I have been trying it for the past 2 weeks.
Regards
Harman.
/dev/lirc0 should be created automatically if lirc_serial is loaded successfully. If it's not created, module was not loaded correctly.
lirc_serial does work with mmio - see 'iommap' module's param. You'll need to set it to 1 for mmio to work.
You'll also need to use 'io' and 'irq' params to setup your address and irq.
I'm using UDOO board with Cortex A9 CPU and could get my mmio and irq information from /proc/tty/driver/IMX-uart.
My kernel is newer though - it's 3.0.35 and I'm not sure if all of that will work in your case.
I was eventually able to load lirc_serial, but it still didn't work, so I had to connect my IR receiver directly to GPIO and write my own kernel driver based on lirc_rpi to make it working: http://funny-embeddings.blogspot.com/2013/12/udoo-adding-ir-and-building-lirc-kernel.html
When building a Kernel Driver out of tree,
i run make like this in the drivers directory, where KERNELDIR either is the path to the kernel source, or to the headers.
make -C $(KERNELDIR) M=$(PWD) modules
when trying to build headers myself using:
make headers_install ARCH=i386 INSTALL_HDR_PATH=$(HEADERSDIR)
i find the export unsuitable to build modules against (without a full kernel source tree)
Several files and folders seem to be missing, like a Makefile, scripts , include/generated/autoconf.h or include/config/auto.conf etc.
Debian does things in an usable way, as described in rules.real, although it does more than is described in Documentation/make/headers_install.txt , which seems to be not the "standard" way.
In short: how do i correctly export linux headers, so i can build external modules against it?
headers_install is meant to export a set of header files suitable to use from a user space point of view. It is the userspace exposed API of the kernel. Let's say you create a wonderful new ioctl, with a custome data structure. This is the kind of information you wan't userspace to know, so that userspace program can use your wonderful new ioctl.
But everything that is not visible from userspace, that is "private" to the kernel, or in other word the internal API, is not exposed to userspace.
So to build an out of tree module, you need either a full configured source tree, or the kernel headers as packaged by your distro. Look for the linux-headers or linux-kernel-headers
package on a Ubuntu / Debian for example.
I believe the kernel make file target of headers_install is meant for the production of Linux header for the production of C library and tool chain and not for the purpose of enabling to build out of tree kernel modules sans full configured kernel source code.
In fact, I'm guessing building out of tree kernel modules without full kernel source code is not supported and is in fact a "hack" created by distributions.