Linux Device Drivers Part -7 : Kernel Modules vs Applications
In this part, we are going to discus about ,
The difference between Kernel Modules (KM) and Applications (APs) in brief.
Before proceeding further, I strongly recommend to watch my earlier videos from "Linux Device Drivers Part -1 to Part 6".
Though there are many differences, to keep it simple and to explain in brief , I have hand picked few differences and listed them as topics form, which can be easily remembered and recollected when required
We compare below 6 topics between Kernel Modules (KM) and Applications (APs)
1. Initialisation
2. Which are Event Driven KM's or AP’s
3. About Exit Procedure in KM's or AP’s
4. Ability to unload a module
5. Linking stage
6. Handling faults
This tutorial covers only brief description of all topics listed. This will help us to understand upcoming sessions with ease
Lets start with our first topic,
1. Initialisation
When we invoke a application, it starts and proceed ahead till end .
Most small and medium sized application programs perform a single task from beginning to end. Take any application in your PC, they start and run till you end them
Whereas every Kernel module registers itself with Kernel in order to serve future requests, and its initialisation function terminates immediately.
In other words, the task of the module's initialisation function is to prepare for later invocation of the module's functions when required.
2. Which are Event Driven KMs or APs
To understand in simple way, say if something happens, an event is raised and that should be served. So, with our current understanding, do you think Kernel is event driven ?
Yes, when a Kernel module is loaded, it invokes init function (hello_init) which conveys Kernel “Here I am, and this is what I can do”. Its conveying kernel, if some events occurs, just let me know i will serve
When Kernel module is unloaded, it invokes exit (hello_exit) which conveys Kernel “I am not there anymore; don’t ask me to do anything else”.
This kind of approach to programming is similar to event-driven programming, but while not all applications are event-driven, each and every Kernel module is even driven.
3. About Exit Procedure in KM or AP’s
I have mentioned earlier, not all applications are event-driven . Imagine we have event driven application
Major difference between event-driven applications and Kernel code is in the exit function.
When an application terminates, it can be lazy in releasing resources or avoids clean up altogether, the exit function of a module must carefully undo everything the init function built up, or the pieces remain around until the system is rebooted.
Sometimes , we end out of memory situations and system may totally crash. Note when application crashes, system can run without any issue, if kernel module crashes, it will kill the process or whole system needs to be rebooted
4. Ability to unload a module
Incidentally, the ability to unload a module is one of the features of modularisation that you'll most appreciate, because it helps cut down development time; you can test successive versions of your new driver without going through the lengthy shutdown/reboot cycle each time.
If you have driver programming experience, you will really appreciate this feature. It save lot of time and effort
With application, you need to either exit it completely and rerun the application. You will not be sure if the memory allocated is dealloated or the task initiated is exited cleanly. It all depends on how you implement the application.
5. Linking Stage
An application can call functions it doesn't define: the linking stage resolves external references using the appropriate library of functions.
printf is one of those callable functions and is defined in libc.
A module, on the other hand, is linked only to the Kernel, and the only functions it can call are the ones exported by the Kernel; there are no libraries to link to. This point is very important. Keep in mind that there are no libraries for kernel modules to link to
The printk function used in hello.c earlier, for example, is the version of printf defined within the kernel and exported to modules. It behaves similarly to the original function, with a few minor differences.
Because no library is linked to kernel modules, source files should never include the usual header files. There are special exceptions like <stdarg.h> .
Only functions that are actually part of the Kernel itself may be used in Kernel modules. Anything related to the Kernel is declared in headers found in the Kernel source tree had to be set up and configured.
Most of the relevant headers live in "include/linux" and "include/asm", but other sub directories of include have been added to host material associated to specific Kernel subsystems.
6. Handling Faults
Another important difference between kernel programming and application programming is in how each environment handles faults.
As briefed earlier , Segmentation fault is harmless during application development and a debugger can always be used to trace the error to the problem in the source code, a kernel fault kills the current process at least, if not the whole system.
The difference between Kernel Modules (KM) and Applications (APs) in brief.
Before proceeding further, I strongly recommend to watch my earlier videos from "Linux Device Drivers Part -1 to Part 6".
Though there are many differences, to keep it simple and to explain in brief , I have hand picked few differences and listed them as topics form, which can be easily remembered and recollected when required
We compare below 6 topics between Kernel Modules (KM) and Applications (APs)
1. Initialisation
2. Which are Event Driven KM's or AP’s
3. About Exit Procedure in KM's or AP’s
4. Ability to unload a module
5. Linking stage
6. Handling faults
This tutorial covers only brief description of all topics listed. This will help us to understand upcoming sessions with ease
Lets start with our first topic,
1. Initialisation
When we invoke a application, it starts and proceed ahead till end .
Most small and medium sized application programs perform a single task from beginning to end. Take any application in your PC, they start and run till you end them
Whereas every Kernel module registers itself with Kernel in order to serve future requests, and its initialisation function terminates immediately.
In other words, the task of the module's initialisation function is to prepare for later invocation of the module's functions when required.
2. Which are Event Driven KMs or APs
To understand in simple way, say if something happens, an event is raised and that should be served. So, with our current understanding, do you think Kernel is event driven ?
Yes, when a Kernel module is loaded, it invokes init function (hello_init) which conveys Kernel “Here I am, and this is what I can do”. Its conveying kernel, if some events occurs, just let me know i will serve
When Kernel module is unloaded, it invokes exit (hello_exit) which conveys Kernel “I am not there anymore; don’t ask me to do anything else”.
This kind of approach to programming is similar to event-driven programming, but while not all applications are event-driven, each and every Kernel module is even driven.
3. About Exit Procedure in KM or AP’s
I have mentioned earlier, not all applications are event-driven . Imagine we have event driven application
Major difference between event-driven applications and Kernel code is in the exit function.
When an application terminates, it can be lazy in releasing resources or avoids clean up altogether, the exit function of a module must carefully undo everything the init function built up, or the pieces remain around until the system is rebooted.
Sometimes , we end out of memory situations and system may totally crash. Note when application crashes, system can run without any issue, if kernel module crashes, it will kill the process or whole system needs to be rebooted
4. Ability to unload a module
Incidentally, the ability to unload a module is one of the features of modularisation that you'll most appreciate, because it helps cut down development time; you can test successive versions of your new driver without going through the lengthy shutdown/reboot cycle each time.
If you have driver programming experience, you will really appreciate this feature. It save lot of time and effort
With application, you need to either exit it completely and rerun the application. You will not be sure if the memory allocated is dealloated or the task initiated is exited cleanly. It all depends on how you implement the application.
5. Linking Stage
An application can call functions it doesn't define: the linking stage resolves external references using the appropriate library of functions.
printf is one of those callable functions and is defined in libc.
A module, on the other hand, is linked only to the Kernel, and the only functions it can call are the ones exported by the Kernel; there are no libraries to link to. This point is very important. Keep in mind that there are no libraries for kernel modules to link to
The printk function used in hello.c earlier, for example, is the version of printf defined within the kernel and exported to modules. It behaves similarly to the original function, with a few minor differences.
Because no library is linked to kernel modules, source files should never include the usual header files. There are special exceptions like <stdarg.h> .
Only functions that are actually part of the Kernel itself may be used in Kernel modules. Anything related to the Kernel is declared in headers found in the Kernel source tree had to be set up and configured.
Most of the relevant headers live in "include/linux" and "include/asm", but other sub directories of include have been added to host material associated to specific Kernel subsystems.
6. Handling Faults
Another important difference between kernel programming and application programming is in how each environment handles faults.
As briefed earlier , Segmentation fault is harmless during application development and a debugger can always be used to trace the error to the problem in the source code, a kernel fault kills the current process at least, if not the whole system.
Hey don't forget to check out youtube version of this article here.
If you like, please dont forget to give a thumbsup :)
Comments
Post a Comment