Skip to main content

Posts

Device Mapper

Recent posts

Virtual Memory

This post discuss about Virtual Memory concept. Generally, we think that virtual memory give us advantage to access memory more than allowed by RAM. However this is not the only reason we use virtual memory on  system. So lets begin!! Virtual Memory is a memory management technique that is implemented using both hardware ( MMU ) and software ( operating system ). It abstracts from the real memory available on a system by introducing the concept of virtual address space , which allows each process thinking of physical memory as a contiguous address space (or collection of contiguous segments). The goal of virtual memory is to map virtual memory addresses generated by an executing program into physical addresses in computer memory. This concerns two main aspects: address translation (from virtual to physical) and virtual address spaces management . The former is implemented on the CPU chip by a specific hardware element called Memory Management Unit or MMU . The lat

Volatile Keyword in C

Few days back I came across this question, searched web to find complete answer explaining every details. However, the answers were scattered at many places So I thought of accumulating the answers to have complete picture of this question. So lets dive in! Volatile in C actually came into existence for the purpose of not caching the values of variable automatically. It will tell the machine not to cache the value of this variable. So it will take the value of the given volatile variable from the main memory every time it encounters it. This mechanism is used because at any time the value can be modified by the OS or any interrupt. So using volatile will help us accessing the value afresh every time. Syntax: To declare a variable volatile, include keyword volatile before or after the data type: // Declaration of variable int volatile foo; volatile int foo; Use: A variable should be declared volatile whenever its value can change unexpectedly. In practice, there are thre

Spinlock implementation in ARM architecture

SEV and WFE are the main instructions used for implementing spinlock in case of ARM architecture . Let's look briefly at those two instructions before looking into actual spinlock implementation. SEV SEV causes an event to be signaled to all cores within a multiprocessor system. If SEV is implemented, WFE must also be implemented. Let's look briefly at those two instructions before looking into actual spinlock implementation. WFE If the Event Register is not set, WFE suspends execution until one of the following events occurs: an IRQ interrupt, unless masked by the CPSR I-bit an FIQ interrupt, unless masked by the CPSR F-bit an Imprecise Data abort, unless masked by the CPSR A-bit a Debug Entry request, if Debug is enabled an Event signaled by another processor using the SEV instruction. In case of  spin_lock_irq( )/spin_lock_irqsave( ) , as IRQs are disabled, the only way to to resume after WFE intruction has executed is to execute SEV ins

Waitqueue

A " wait queue " in the Linux kernel is a data structure to manage threads that are waiting for some condition to become true; they are the normal means by which threads block (or "sleep") in kernel space. While writing modules there might be situations where one might have to wait for input some condition to occur before proceeding further. Tasks that need such behavior can make use of the sleep functionality available in the kernel.  In Linux sleeping is handled by a data structure called wait queue, which is nothing but a list of processes waiting for an input or  event. To manage a wait queue ,we need a structure of the kind wait_queue_head_t, which is defined in linux/wait.h.  Wait queue head can be initialized in the following ways  Statically using:  DECLARE_WAIT_QUEUE_HEAD(name);  Dynamically using :  wait_queue_head_t my_queue; init_waitqueue_head(name), where "name" is name of queue on which task will be put to sleep.   Once

Explanation of "struct task_struct"

This document tries to explain clearly what fields in the structure task_struct do. It's not complete and everyone is welcome to add information. Let's start by saying that each process under Linux is defined by a structure task_struct. The following information are available (on kernel 2.6.7): - volatile long state;    /* -1 unrunnable, 0 runnable, >0 stopped */ - struct thread_info *thread_info; a pointer to a thread_info... - atomic_t usage; used by get_task_struct(). It's also set in kernel/fork.c. This value acts like a reference count on the task structure of a process. It can be used if we don't want to hold the tasklist_lock. - unsigned long flags;    /* per process flags, defined below */ process flag can be, for example, PF_DEAD when exit_notify() is called. List is of possible values is in include/linux/sched.h - unsigned long ptrace; used by ptrace a system call that provides the ability to a parent process to observe and con