The collection of files and their complete history are stored in a repository.

The process of creating different versions (snapshots) in the repository is depicted in the following graphic. Please note that this picture fits primarily to Git, other version control systems like CVS don’t create snapshots but store file deltas.

Compatibility Mode phase transitions:
1. Write the data to the data register
2. Program reads the status register to check that the printer is not BUSY
3. If not BUSY, then Write to the Control Register to assert the STROBE line
4. Write to the Control register to de-assert the STROBE line

2. Nibble Mode
The Nibble mode is the most common way to get reverse channel data from a printer or peripheral. This mode is usually combined with the Compatibility mode or a proprietary forward channel mode to create a complete bi-directional channel.
All of the standard parallel ports provide 5 lines from the peripheral to the PC to be used for external status indications. Using these lines, a peripheral can send a byte of data (8-bits) by sending 2 nibbles (4-bits) of information to the PC in two data transfer cycles. Unfortunately, since the nACK line is generally used to provide a peripheral interrupt, the bits used to transfer a nibble are not conveniently packed into the byte defined by the Status register. For this reason, the software must read the status byte and then manipulate the bits in order to get a correct byte.

Nibble Mode phase transitions:
1. Host signals ability to take data by asserting HostBusy low
2. Peripheral responds by placing first nibble on status lines
3. Peripheral signals valid nibble by asserting PtrClk low
4. Host sets HostBusy high to indicate that it has received the nibble and is not yet ready for another nibble.
5. Peripheral sets PtrClk high to acknowledge host
6. States 1 through 5 repeat for the second nibble

3. Byte Mode
With later implementations of the parallel port interface, some manufacturers, led by IBM on the PS/2 parallel port, added the capability to disable the drivers used for driving the data lines, and allowed the data port to become an input read data port. This enables a peripheral to send an entire byte of data to the PC in one data transfer cycle by using the 8 data lines, rather than the two cycles required using the Nibble mode.
This ability enables a Byte mode for reverse channel data transfer that can be used to provide data rates into the PC approaching that of the Compatibility mode, from the PC. This type of port is sometimes referred to as a “enhanced bi-directional” port, and has caused some confusion when mistaken for an Enhanced Parallel Port (EPP).

Byte Mode signal transitions:
1. Host signals ability to take data by asserting HostBusy low
2. Peripheral responds by placing first byte on data lines
3. Peripheral signals valid byte by asserting PtrClk low
4. Host sets HostBusy high to indicate that it has received the and is not yet ready for another byte
5. Peripheral sets PtrClk high to acknowledge host. Host pulses HostClk as an acknowledgement to the peripheral
6. States 1 through 5 repeat for additional bytes

1. Semaphore

2. Mutex

3. RW_Semaphore

4. Completion

5. Spinlock

1.3
date    2014.01.10.09.25.47;    author root;    state Exp;
branches;
next    1.2;

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

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

desc
@Header file for init.c and exit .c
@

1.3
log
@header file now only includes header files and macros.
@

——————————————————————————————————————————————————–

head    1.3;
access;
symbols;
locks; strict;
comment    @ * @;

1.3
date    2014.01.10.09.26.29;    author root;    state Exp;
branches;
next    1.2;

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

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

desc
@all the declerations are done in this file for init.c and exit.c
@

1.3
log
@this file now has the extern declerations
@

——————————————————————————————————————————————————–

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

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

desc
@this file has the mapping of the file_operations fops
open and close.
@

——————————————————————————————————————————————————–

head    1.3;
access;
symbols;
locks; strict;
comment    @ * @;

1.3
date    2014.01.10.09.27.06;    author root;    state Exp;
branches;
next    1.2;

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

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

desc
@source code fro initialization function
@

1.3
log
@added the definitions of extern declerations
@

——————————————————————————————————————————————————–

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

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

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

desc
@source code for clean-up function.
@

1.2
log
@added the definitions of extern declerations
@

——————————————————————————————————————————————————–

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

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

desc
@routine for opening the node between kernel and user space
@

——————————————————————————————————————————————————–

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

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

desc
@routine for releasing the node between kernel and user space

——————————————————————————————————————————————————–

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

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

desc
@the application which is calling the driver for file_operations fops.
@

——————————————————————————————————————————————————–

head    1.2;
access;
symbols;
locks; strict;
comment    @# @;

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

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

desc
@script file for the code
@

1.2
log
@added the command MKNOD
added the command make app
added the command unlink
@

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

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

desc
@Header file for init.c and exit .c
@

1.2
log
@nothing is changed as per the project
@

———————————————————————————————————————————————–

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

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

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

desc
@all the declerations are done in this file for init.c and exit.c
@

1.2
log
@declared the scull function for multiple devices
@

———————————————————————————————————————————————–

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

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

desc
@source code for clean-up function.
@

———————————————————————————————————————————————–

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

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

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

desc
@source code fro initialization function
@

1.2
log
@created for multiple devices using for loop and exported the function to Symbol Table
@

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

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

desc
@Header file for init.c and exit .c

—————————————————————————————————————————————————–

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

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

desc
@all the declerations are done in this file for init.c and exit.c

—————————————————————————————————————————————————–

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

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

desc
@source code for initialization function

—————————————————————————————————————————————————–

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

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

desc
@source code for clean-up function.

—————————————————————————————————————————————————–

head    1.1;
access;
symbols;
locks; strict;
comment    @# @;

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

desc
@script file for the code

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

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

desc
@source file for ftp server

————————————————————————————————————————————-

log file for client

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

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

desc
@source code for client for FTP

1. Sometimes it is very useful to make a program appear to do two things at once. The classic example is to perform a real-time word count on a document while still editing the text. One thread can manage the user’s input and perform editing. The other, which can see the same document content, can continuously update a word count variable. The first thread (or even a third one) can use this shared variable to keep the user informed. Another example is a multithreaded database server
   where an apparent single process serves multiple clients, improving the overall data throughput by servicing some requests while blocking others, waiting for disk activity. For a database server, this apparent multitasking is quite hard to do efficiently in different processes, because the  requirements for locking and data consistency cause the different processes to be very tightly coupled. This can be done much more easily with multiple threads than with multiple processes.
2. The performance of an application that mixes input, calculation, and output may be improved by running these as three separate threads. While the input or output thread is waiting for a connection, one of the other threads can continue with calculations. A server application pro-cessing multiple network connects may also be a natural fit for a multithreaded program.
3. Now that multi-cored CPUs are common even in desktop and laptop machines, using multiple threads inside a process can, if the application is suitable, enable a single process to better utilize the hardware resources available.
4. In general, switching between threads requires the operating system to do much less work than switching between processes. Thus, multiple threads are much less demanding on resources than multiple processes, and it is more practical to run programs that logically require many threads of execution on single-processor systems. That said, the design difficulties of writing a multithreaded program are significant and should not be taken lightly.

Threads also have drawbacks:

1. Writing multithreaded programs requires very careful design. The potential for introducing subtle timing faults, or faults caused by the unintentional sharing of variables in a multithreaded program is considerable. Alan Cox (the well respected Linux guru) has commented that threads are also known as “how to shoot yourself in both feet at once.”
2. Debugging a multithreaded program is much, much harder than debugging a single-threaded one, because the interactions between the threads are very hard to control.
3. A program that splits a large calculation into two and runs the two parts as different threads will not necessarily run more quickly on a single processor machine, unless the calculation truly allows multiple parts to be calculated simultaneously and the machine it is executing on has multiple processor cores to support true multiprocessing.

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

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

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

desc
@main server file for socket using AF_UNIX
@

1.2
log
@indent correction
———————————————————————————————————————————————–

log file for client

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

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

desc
@source code for client1 of socket AF_UNIX

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

1.1
date    2013.12.28.07.56.32;    author emblogic;    state Exp;
branches;
next    ;

desc
@server with thread is created.
data from client to thread .
@

———————————————————————-

log file for request client

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

1.1
date    2013.12.28.07.58.32;    author emblogic;    state Exp;
branches;
next    ;

desc
@requesting client using semaphore and shared memory sucssecfully created.
@

———————————————————————————————————————————

log file for processing client

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

1.1
date    2013.12.28.07.58.43;    author emblogic;    state Exp;
branches;
next    ;

desc
@processing client using shared memory is created.
@

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

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

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

desc
@This is the main server source file for client server project using message queue.
@

1.2
log
@This is the final source code of server.
change the value of msg_id of msg_st.
————————————————————————————————

Log File For Req_add
head    1.1;
access;
symbols;
locks
root:1.1; strict;
comment    @ * @;

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

desc
@This is the request client for addition.
@

1.1
log
@Initial revision

—————————————————————————————-

Log file for Req_sub

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

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

desc
@This is the source code of requesting client for substration.
@

1.1
log
@Initial revision

—————————————————————————————-

log file for Req_Mul

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

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

desc
@This is source code of requesting client for multiplication.
@

1.1
log
@Initial revision

—————————————————————————————

Log file For Proccesing_Add

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

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

desc
@This is the source code of processing client for addition.
@

1.1
log
@Initial revision

—————————————————————————————

Log file For Proccesing_Sub

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

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

desc
@This is source code of processing client for substraction.
@

1.1
log
@Initial revision

—————————————————————————————

Log file For Proccesing_Mul

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

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

desc
@This is source code of processing client for multiplcation.
@

1.1
log
@Initial revision

—————————————————————————————

The Linux IPC (Inter-process communication) facilities provide a method for multiple processes to communicate with one another. There are several methods of IPC available to Linux C programmers.

These facilities, when used effectively, provide a solid framework for client/server development on any Linux system (including Linux).
Half-duplex Linux pipes
Simply put, a pipe is a method of connecting the standard output of one process to the standard input of another. Pipes are the eldest of the IPC tools, having been around since the earliest incarnations of the Linux operating system. They provide a method of one-way communications (hence the term half-duplex) between processes.

This feature is widely used, even on the Linux command line (in the shell).

ls | sort | lp

The above sets up a pipeline, taking the output of ls as the input of sort, and the output of sort as the input of lp. The data is running through a half duplex pipe, traveling (visually) left to right through the pipeline.

Although most of us use pipes quite religiously in shell script programming, we often do so without giving a second thought to what transpires at the kernel level.

When a process creates a pipe, the kernel sets up two file descriptors for use by the pipe. One descriptor is used to allow a path of input into the pipe (write), while the other is used to obtain data from the pipe (read). At this point, the pipe is of little practical use, as the creating process can only use the pipe to communicate with itself.
If the process sends data through the pipe (fd0), it has the ability to obtain (read) that information from fd1. However, there is a much larger objective of the simplistic sketch above. While a pipe initially connects a process to itself, data traveling through the pipe moves through the kernel. Under Linux, in particular, pipes are actually represented internally with a valid inode. Of course, this inode resides within the kernel itself, and not within the bounds of any physical file system. This particular point will open up some pretty handy I/O doors for us, as we will see a bit later on.
At this point, the pipe is fairly useless. After all, why go to the trouble of creating a pipe if we are only going to talk to ourself? At this point, the creating process typically forks a child process. Since a child process will inherit any open file descriptors from the parent, we now have the basis for multiprocess communication (between parent and child).
We see that both processes now have access to the file descriptors which constitute the pipeline. It is at this stage, that a critical decision must be made. In which direction do we desire data to travel? Does the child process send information to the parent, or vice-versa? The two processes mutually agree on this issue, and proceed to “close” the end of the pipe that they are not concerned with. For discussion purposes, let’s say the child performs some processing, and sends information back through the pipe to the parent.
Construction of the pipeline is now complete! The only thing left to do is make use of the pipe. To access a pipe directly, the same system calls that are used for low-level file I/O can be used (recall that pipes are actually represented internally as a valid inode).

To send data to the pipe, we use the write() system call, and to retrieve data from the pipe, we use the read() system call. Remember, low-level file I/O system calls work with file descriptors! However, keep in mind that certain system calls, such as lseek(), do not work with descriptors to pipes.