Tuesday, 30 September 2014
Thursday, 18 September 2014
Sunday, 14 September 2014
Tuesday, 5 August 2014
[Operating System] Mutex vs Semaphore
Mutex and semaphore are used for
providing mutual exclusion property, and these are Kernel resources to provide synchronization
services.
Now comes to differences:
- Mutex job is mainly to provide Mutual Exclusion and Semaphore is mainly used for resource sharing.
- Mutex serializes the access to critical section of code i.e. only one process/thread can access this code at a time. (Single Resource Manager)
- Semaphore looks like Mutex if the semaphore count/value is equal to 1 since if one thread acquires lock then other thread trying to access the critical section should wait until the 1st thread releases the acquired lock. But, the purpose of using the Mutex and Semaphore is different.
- Semaphores are of two types based
on this value
Semaphore value = 1, then binary semaphore Semaphore values > 1 then counting semaphore i.e. it can handle multiple identical resources with its count value. - Mutex is just a lock, whoever acquired it they should release that lock so that next process/thread which is in the queue will get this lock. There is no signal mechanism for Mutex. But, Semaphore can signal the other process/threads by simply increment the semaphore value by 1. So, Semaphores are mainly used for synchronizing the multiple processes/threads.
Mutex
|
Semaphore
|
A Locking mechanism used to synchronize access to a resource. Mutex
is just a Lock.
|
A Signaling mechanism and used for message passing mechanism
|
Only one task can acquire the Mutex and can release it. Mutex
maintains ownership info
|
Lacks of ownership details
|
Mutex is used within a process by multiple threads
|
Semaphore can be used across processes
|
Mutex can be used only in userspace
|
Semaphore can be used in Kernel space also
|
What is Critical Section?
Definition: A Critical section is a piece of code that
accesses shared resources that must not be concurrently accessed by more than one
thread of execution.
So, some Synchronization mechanism are being used to ensure
this for ex: Mutex and Semaphores
What is Mutual Exclusion Property?
It is a property to ensure that no two concurrently
executing threads/processes are in their critical section at the same time.
What is Synchronization?
Definition: Synchronization is a mechanism to ensure that
two concurrently executing threads/processes do not execute specific portion of
code/program at the same time. This specific portion of code/program is called
as Critical Section.
Reference: Wikipedia and GeeksForGeeks
Sunday, 6 July 2014
[Kernel Programming] Cross compile a module for ARM platform
My initial Kernel Programming posts in this blog contains the following info
int init_module(void) {
printk(KERN_ALERT "1st module program: Module Inserted\n");
return 0;
}
void cleanup_module() {
printk(KERN_ALERT "1st module program: Module Removed\n");
}
- how to write a module,
- how to compile a module using a Makefile,
- how to insert/remove a module into linux platform machine
Please check my previous posts for this information below
Now, I will share the required data for writing a simple module for ARM platform in this post. Please follow below steps for the same.
[Note: You should have working linux kernel source code, and able to flash this code on any android device for testing this module.]
Step-1: Goto Linux Kernel source directory and set $TOP variable with this path
Example: If kernel source code is present on home directory then
export TOP = $(/home/your-machine-username/kernel_source_dir)
Step-2: Goto kernel folder from $TOP and create a temporary directory there.
Example: 1. cd $TOP/kernel
2. mkdir test
Step-3: Now, add simple module file in the test directory.
Example: simple.c
#include<linux/module.h> /* Needed by all modules *MUST* */
int init_module(void) {
printk(KERN_ALERT "1st module program: Module Inserted\n");
return 0;
}
void cleanup_module() {
printk(KERN_ALERT "1st module program: Module Removed\n");
}
Step-4: Add Makefile for this module.
Example: Makefile
obj-m += simple.o
Only above one line is enough here.
Step-5: Now, we have two files in the test directory. They are simple.c and Makefile. Goto kernel folder (cd $TOP/kernel)
Step-6: Compile our test module using make command
make -j4 ARCH=arm CROSS_COMPILE=$TOP/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/arm-linux-androideabi- O=$TOP/out/target/product/<product-name>/obj/KERNEL M=$TOP/kernel/test
Options description:
-j4: Describes how many threads GNU compiler will make use of, to compile the module. Normally, the number(just after 'j') should be twice the number of CPU cores available for your pc.
ARCH: Describes the destination platform architecture. The name of the architecture can be found in the $TOP/kernel/arch/ directory.
Example: arm platform: $TOP/kernel/arch/arm
arm64 platform: $TOP/kernel/arch/arm64
CROSS_COMPILE: Specifies the correct tools path to be used for generating object files and binary files for our test module.
O: Specifies the path to where the generated object files have to go.
M: Path to input module directory to compile the required module.
Step-7: After successful compilation of our test module, we can see simple.ko file get generated in $TOP/kernel/test directory.
Step-8: Now, insert this module into destination platform using insmod command.
If the destination platform is accessed through adb shell then do the following.
- sudo adb push $TOP/kernel/test/simple.ko /data
- sudo adb shell
- su -
- cd /data
- Insert our test module (simple.ko) using below command
insmod simple.ko - We can see the output of the insmod using below command
dmesg
And observe, "1st module program: Module Inserted" got printed in the log - Use below command for removing our module
rmmod simple
I hope this data is useful to compile any module for different platform.
References:
https://www.kernel.org/doc/Documentation/kbuild/kbuild.txt
Tuesday, 8 April 2014
[Kernel Programming] Allocation of memory in Kernel
Allocation of memory in Kernel
kmalloc() | kzalloc() | kcalloc() | vmalloc() |
---|---|---|---|
Allocates contiguous physical blocks of memory in byte-sized chunks | Allocates contiguous physical blocks of memory | Allocates memory for an array | same as kmalloc, except it allocates memory that is only virtually contiguous |
Memory is not set to zero | Memory is set to zero | Memory is set to zero | underling physical memory can be discontiguous |
void * kmalloc (size_t size, int flags) | void * kzalloc (size_t size, int flags) | void * kcalloc (size_t n, size_t size, unsigned int __nocast flags); | void * vmalloc (unsigned long size) |
Depends on the flag used, it may sleep | Depends on the flag used, it may sleep | Depends on the flag used, it may sleep | Can sleep, so don’t use it in interrupt context |
Can allocate upto 4MBytes | Same as kmalloc | Need to check ? | Can obtain very large regions of memory |
Simple and fast | Simple, preferable and fast | Simple and fast | Slow compare to kmalloc |
Vmalloc():
Slower and not advisable if memory requirement is less. Because,
- Makes non-contiguous physical memory to continuous virtual memory
- Setting up the page table entries
- Pages obtained from vmalloc() must be mapped to their individual pages since physical memory is not contiguous
- Results in much greater TLB, performance is affected.
Note: malloc()
function also works in same manner. i.e. allocated memory in continuous in
virtual address space of the processor, but there is no guarantee that they are
contiguous in the physical address space (physical RAM)
Flag: controls the behavior of memory allocation
and divided into 3 groups
–Action modifiers: How to allocate memory.
Ex:
can sleep or not
–Zone modifiers: Where the request should
be satisfied. (ex: DMA buffers)
–Types: types of allocation
FLAG Type | Action Modifier | Zone Modifier |
---|---|---|
GFP_KERNEL | (__GFP_WAIT | __GFP_IO | __GFP_FS) | -NA- |
GFP_ATOMIC | __GFP_HIGH | -NA- |
GFP_DMA | __GFP_DMA |
GFP_ATOMIC: Allocation is High priority and does not sleep. This flag will be used in Interrupt handlers, bottom halves where kernel should not sleep
GFP_KERNEL: Allocation will be Normal priority and can be used in process context, and safe to sleep
Action Modifiers and Zone Modifiers:
__GFP_HIGH: The kernel
can access emergency pools.
__GFP_WAIT: The
kernel can sleep
__GFP_IO: The
kernel can start disk I/O
__GFP_FS: The
kernel can start filesystem I/O
__GFP_DMA:
Allocate only
DMA-capable memory
References:
Third Edition of Linux Device Drivers,
by
Jonathan Corbet
Tuesday, 18 March 2014
Monday, 3 March 2014
Subscribe to:
Posts (Atom)