Always, contiguous(adjacent) memory locations are used to store structure members in memory. Consider below example to understand how memory is allocated for structures.

Example program for memory allocation in C structure

 Output:

           There are 5 members declared for structure in above program. In 32 bit compiler, 4 bytes of memory is occupied by int datatype. 1 byte of memory is occupied by char datatype and 4 bytes of memory is occupied by float datatype.

Please refer below table to know from where to where memory is allocated for each datatype in contiguous (adjacent) location in memory.

           The pictorial representation of above structure memory allocation is given below. This diagram will help you to understand the memory allocation concept in C very easily.

The task of fulfilling an allocation request consists of locating a block of unused memory of sufficient size. Memory requests are satisfied by allocating portions from a large pool of memory called the heap. At any given time, some parts of the heap are in use, while some are “free” (unused) and thus available for future allocations. Several issues complicate implementation, such as external fragmentation, which arises when there are many small gaps between allocated memory blocks, which invalidates their use for an allocation request. The allocator’s metadata can also inflate the size of (individually) small allocations. This is managed often by chunking. The memory management system must track outstanding allocations to ensure that they do not overlap and that no memory is ever “lost” as a memory leak.

IEEE 1284 can operate in five modes:

1.   Compatibility Mode, also known as Centronics standard or SPP, is a uni-directional implementation with only a few differences from the original Centronics design. This mode is almost exclusively used for printers. The only signals that the printer can send back to the host are some fixed-meaning status lines that signal common error conditions, such as the printer running out of paper.

2.  Nibble Mode is an interface that allows the device to transmit data four bits (a nibble) at a time, (re)using four of the status lines of Compatibility Mode for data. This is the Bi-tronics mode introduced by HP and is generally used for enhanced printer status. Although never officially supported with these, Nibble Mode works with most of the pre-IEEE-1284 Centronics interfaces as well.

3. Byte Mode, also known as “Bi-Directional” (although all modes except Compatibility Mode are in fact bi-directional), is a half-duplex mode that allows the device to transmit eight bits at a time using the same data lines that are used for the other direction. This mode is supported on a minority of pre-IEEE-1284 interfaces as well, such as those built into the IBM PS/2 computers; because of this, it is sometimes unofficially called the PS/2 mode.

4.   Enhanced Parallel Port (EPP) is a half-duplex bi-directional interface designed to allow devices like printers, scanners, or storage devices to transmit large amounts of data while quickly being able to switch channel direction. EPP can provide up to 2 MByte/s bandwidth, approximately 15 times the speed achieved with normal parallel-port communication with far less CPU overhead.[1]

5.Extended Capability Port (ECP) is a half-duplex bi-directional interface similar to EPP, except that PC implementations use direct memory access (usually ISA DMA on channel 3) to provide even faster data transfer than EPP by having the ISA DMA hardware and the parallel port interface hardware handle the work of transferring the data instead of letting the CPU do this work. Many devices that interface using this mode support RLE compression. ECP can provide up to 2.5 MByte/s of bandwidth, which is the natural limit of 8-bit ISA DMA.[2] An ECP interface on a PC can improve transfers to pre-IEEE-1284 printers as well, by reducing the CPU load during the transfer ; however, the transfer in that case is unidirectional.

Most recent computers that include a parallel port can operate the port in ECP or EPP mode, or both simultaneously.

IEEE-1284 requires that bi-directional device communication is always initiated in Nibble Mode. If the host receives no reply in this mode, it will assume that the device is a legacy printer, and enter Compatibility Mode. Oth

In most implementations, character devices use unbuffered input and output routines. The system reads each character from the device immediately or writes each character to the device immediately.

There are two major ways for a kernel module to talk to processes. One is through device files (like the files in the /dev directory), the other is to use the proc file system. Since one of the major reasons to write something in the kernel is to support some kind of hardware device, we’ll begin with device files.

The original purpose of device files is to allow processes to communicate with device drivers in the kernel, and through them with physical devices (modems, terminals, etc.). The way this is implemented is the following.

Each device driver, which is responsible for some type of hardware, is assigned its own major number. The list of drivers and their major numbers is available in /proc/devices. Each physical device managed by a device driver is assigned a minor number. The /dev directory is supposed to include a special file, called a device file, for each of those devices, whether or not it’s really installed on the system.

1.Register the driver by using the new mechanism, allocate the memory , initialise and add the cdev to device table.

head    1.2;
access;
symbols;
locks
root:1.2; strict;
comment    @ * @;

1.2
date    2014.01.06.11.00.57;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.10.57.33;    author root;    state Exp;
branches;
next    ;

desc
@this is source code for register device by the new mechnism and allocate the the memory by using kmalloc and add cdev to the device table.
@

1.2
log
@removed the  errors.
@

2.After registration, allocation, and adding the cdev to device table, delete the cdev form device table, deallocate the memory and unregister the driver.

head    1.2;
access;
symbols;
locks
root:1.2; strict;
comment    @ * @;

1.2
date    2014.01.06.11.03.44;    author root;    state Exp;
branches;
next    1.1;

1.1
date    2014.01.06.10.58.52;    author root;    state Exp;
branches;
next    ;

desc
@this is souce code for cleanup function in which unregister the driver by new mechnism and deallocate the mem.& cdev remove it in cleanup function.
@

1.2
log
@removed the errors.
@

head    1.1;
access;
symbols;
locks
root:1.1; strict;
comment    @ * @;

1.1
date    2014.01.04.11.18.09;    author root;    state Exp;
branches;
next    ;

desc
@this is the source code of init function for initialization in device driver
@

1.1
log
@Initial revision
@

log file of exit function

head    1.1;
access;
symbols;
locks
root:1.1; strict;
comment    @ * @;

1.1
date    2014.01.04.11.18.43;    author root;    state Exp;
branches;
next    ;

desc
@this is the source of exit function for clean up the device driver
@

1.1
log
@Initial revision

1.1
date  2013.12.30.05.37.11;    author root;      state Exp;
branches;
next  ;

desc
@this is server implemented by socket and create usrname & password for server
@

1.1
log
@Initial revision
@
text

head  1.1;
access;
symbols;
locks
root:1.1; strict;
comment     @ * @;

1.1
date  2013.12.30.05.36.51;    author root;      state Exp;
branches;
next  ;

desc
@this is client implemented by using socket
@

1.1
log
@Initial revision
@
text

First of all, let’s understand the actual meaning of: IPC. IPC is an abbreviation that stands for Inter-process Communication. It denotes a set of system calls that allows a User Mode process to:

1. Synchronize itself with other processes by means of ‘Semaphores’.
2. Send messages to other processes or receive messages from them.
3. Share a memory area with other processes.

IPC was introduced in a development UNIX variant called “Columbus Unix” and later adopted by AT&T’s System III. It is now commonly found in most UNIX systems,  and provides three methods of communication: message queues, semaphores, and shared segments. Like BSD mmap, System V IPC uses files to identify shared segments. Unlike BSD, System V uses these files only for naming. Their contents have nothing to do with the initialization of the shared segment. IPC data structures are created dynamically when a process requests an IPC Resource, i.e. a semaphore, a message queue, or a shared memory segment. All of these IPC Resources would be discussed in detail later on. Before we dive deep into the subject matter, there are a few things that I would like to explain at the very beginning. They are as follows:

1. The mechanism in which User Mode processes synchronize themselves and exchange data is referred to as “Inter-process Communication (IPC)” in UNIX Systems (that includes Linux too). But in what way exactly do terms like: Semaphores, Shared Memory and Message Queues relate to IPC? All readers must note that Semaphores, Shared Memory and Message Queues do relate to IPC in a very special way, since Semaphores, Shared Memory and Message Queues are “Inter-process Communication Resources” or “Inter-process Communication Facilities”, and different in the way they represent IPC from “Inter-process Communication Mechanisms” like Pipes and FIFOs. Semaphores, Shared Memory and Message Queues are System V (AT&T System V.2 release of UNIX) IPC facilities, and they represent wrapper functions that have been developed and inserted in suitable libraries to harness the energy and beauty of IPC mechanisms. More on this later.
2. Data sharing among processes can be obtained by storing data in temporary files protected by locks. But this mechanism is never implemented as it proves costly since it requires accesses to the disk filesystem. For that reason, all UNIX Kernels include a set of system calls that supports process communications without interacting with the filesystem.

Application programmers have a variety of needs that call for different communication mechanisms. Some of the basic mechanisms that UNIX systems, GNU/Linux is particular has to offer are:

1. Pipes and FIFOs: Mainly used for implementing producer/consumer interactions among processes. Some processes will fill the pipe with data while others will extract from it.
2. Semaphores: Here we refer to (NOT the POSIX Realtime Extension Semaphores applied to Linux Kernel Threads), but System V semaphores which apply to User Mode processes. Used for locking critical sections of code.
3. Message Queues: To set up a message queue between processes is a way to exchange short blocks (called messages) between two processes in an asynchronous way.
4. Shared Memory: A mechanism (specifically a resource) applied when processes need to share large amounts of data in an efficient way.

Another commonly used data communication mechanism in networks, “Sockets” will NOT be discussed here since it requires a long discussion of networking. In this article, we will explore all the above-mentioned IPC mechanisms and System V IPC facilities at our disposal.

desc
@this is the client implemented with socket.
@

desc
@this is code of server which is implemented with the use of socket.
@
~
~