Although there are already a lot of good security features built into Linux-based systems, one very important potential vulnerability can exist when local access is granted – - that is file permission based issues resulting from a user not assigning the correct permissions to files and directories. So based upon the need for proper permissions, I will go over the ways to assign permissions and show you some examples where modification may be necessary.

Basic File Permissions

Permission Groups

Each file and directory has three user based permission groups:

• owner – The Owner permissions apply only the owner of the file or directory, they will not impact the actions of other users.
• group – The Group permissions apply only to the group that has been assigned to the file or directory, they will not effect the actions of other users.
• all users – The All Users permissions apply to all other users on the system, this is the permission group that you want to watch the most.

Permission Types

Each file or directory has three basic permission types:

• read – The Read permission refers to a user’s capability to read the contents of the file.
• write – The Write permissions refer to a user’s capability to write or modify a file or directory.
• execute – The Execute permission affects a user’s capability to execute a file or view the contents of a directory.

Viewing the Permissions

You can view the permissions by checking the file or directory permissions in your favorite GUI File Manager (which I will not cover here) or by reviewing the output of the \”ls -l\” command while in the terminal and while working in the directory which contains the file or folder.

The permission in the command line is displayed as: _rwxrwxrwx 1 owner:group

1. User rights/Permissions
   1. The first character that I marked with an underscore is the special permission flag that can vary.
   2. The following set of three characters (rwx) is for the owner permissions.
   3. The second set of three characters (rwx) is for the Group permissions.
   4. The third set of three characters (rwx) is for the All Users permissions.
2. Following that grouping since the integer/number displays the number of hardlinks to the file.
3. The last piece is the Owner and Group assignment formatted as Owner:Group.

Modifying the Permissions

When in the command line, the permissions are edited by using the command chmod. You can assign the permissions explicitly or by using a binary reference as described below.

Explicitly Defining Permissions

To explicity define permissions you will need to reference the Permission Group and Permission Types.

The Permission Groups used are:

• u – Owner
• g – Group
• o or a – All Users

The potential Assignment Operators are + (plus) and – (minus); these are used to tell the system whether to add or remove the specific permissions.

The Permission Types that are used are:

• r – Read
• w – Write
• x – Execute

So for an example, lets say I have a file named file1 that currently has the permissions set to _rw_rw_rw, which means that the owner, group and all users have read and write permission. Now we want to remove the read and write permissions from the all users group.

To make this modification you would invoke the command: chmod a-rw file1
To add the permissions above you would invoke the command: chmod a+rw file1

As you can see, if you want to grant those permissions you would change the minus character to a plus to add those permissions.

Using Binary References to Set permissions

Now that you understand the permissions groups and types this one should feel natural. To set the permission using binary references you must first understand that the input is done by entering three integers/numbers.

A sample permission string would be chmod 640 file1, which means that the owner has read and write permissions, the group has read permissions, and all other user have no rights to the file.

The first number represents the Owner permission; the second represents the Group permissions; and the last number represents the permissions for all other users. The numbers are a binary representation of the rwx string.

• r = 4
• w = 2
• x = 1

You add the numbers to get the integer/number representing the permissions you wish to set. You will need to include the binary permissions for each of the three permission groups.

So to set a file to permissions on file1 to read _rwxr_____, you would enter chmod 740 file1.

Owners and Groups

I have made several references to Owners and Groups above, but have not yet told you how to assign or change the Owner and Group assigned to a file or directory.

You use the chown command to change owner and group assignments, the syntax is simple chown owner:group filename, so to change the owner of file1 to user1 and the group to family you would enter chown user1:family file1.

Advanced Permissions

The special permissions flag can be marked with any of the following:

• _ – no special permissions
• d – directory
• l - The file or directory is a symbolic link
• s – This indicated the setuid/setgid permissions. This is not set displayed in the special permission part of the permissions display, but is represented as a s in the read portion of the owner or group permissions.
• t – This indicates the sticky bit permissions. This is not set displayed in the special permission part of the permissions display, but is represented as a t in the executable portion of the all users permissions

Setuid/Setgid Special Permissions

The setuid/setguid permissions are used to tell the system to run an executable as the owner with the owner\’s permissions.

Be careful using setuid/setgid bits in permissions. If you incorrectly assign permissions to a file owned by root with the setuid/setgid bit set, then you can open your system to intrusion.

You can only assign the setuid/setgid bit by explicitly defining permissions. The character for the setuid/setguid bit is s.

So do set the setuid/setguid bit on file2.sh you would issue the command chmod g+s file2.sh.

Sticky Bit Special Permissions

The sticky bit can be very useful in shared environment because when it has been assigned to the permissions on a directory it sets it so only file owner can rename or delete the said file.

You can only assign the sticky bit by explicitly defining permissions. The character for the sticky bit is t.

To set the sticky bit on a directory named dir1 you would issue the command chmod +t dir1.

When Permissions Are Important

To some users of Mac- or Windows-based computers you don’t think about permissions, but those environments don’t focus so aggressively on user based rights on files unless you are in a corporate environment. But now you are running a Linux-based system and permission based security is simplified and can be easily used to restrict access as you please.

So I will show you some documents and folders that you want to focus on and show you how the optimal permissions should be set.

• home directories - The users\’ home directories are important because you do not want other users to be able to view and modify the files in another user\’s documents of desktop. To remedy this you will want the directory to have the drwx______ (700) permissions, so lets say we want to enforce the correct permissions on the user user1\’s home directory that can be done by issuing the command chmod 700 /home/user1.
• bootloader configuration files - If you decide to implement password to boot specific operating systems then you will want to remove read and write permissions from the configuration file from all users but root. To do you can change the permissions of the file to 700.
• system and daemon configuration files - It is very important to restrict rights to system and daemon configuration files to restrict users from editing the contents, it may not be advisable to restrict read permissions, but restricting write permissions is a must. In these cases it may be best to modify the rights to 644.
• firewall scripts – It may not always be necessary to block all users from reading the firewall file, but it is advisable to restrict the users from writing to the file. In this case the firewall script is run by the root user automatically on boot, so all other users need no rights, so you can assign the 700 permissions.

Other examples can be given, but this article is already very lengthy, so if you want to share other examples of needed restrictions please do so in the comments.

Comments Welcome

If you have anything to add or want to make a comment or correction please do so in the comments. I look forward to your feedback and wish you the best in your future with Linux-based systems.

Although there are already a lot of good security features built into Linux-based systems, one very important potential vulnerability can exist when local access is granted – - that is file permission based issues resulting from a user not assigning the correct permissions to files and directories. So based upon the need for proper permissions, I will go over the ways to assign permissions and show you some examples where modification may be necessary.

Basic File Permissions

Permission Groups

Each file and directory has three user based permission groups:

owner – The Owner permissions apply only the owner of the file or directory, they will not impact the actions of other users.
group – The Group permissions apply only to the group that has been assigned to the file or directory, they will not effect the actions of other users.
all users – The All Users permissions apply to all other users on the system, this is the permission group that you want to watch the most.

Permission Types

Each file or directory has three basic permission types:

read – The Read permission refers to a user’s capability to read the contents of the file.
write – The Write permissions refer to a user’s capability to write or modify a file or directory.
execute – The Execute permission affects a user’s capability to execute a file or view the contents of a directory.

Viewing the Permissions

You can view the permissions by checking the file or directory permissions in your favorite GUI File Manager (which I will not cover here) or by reviewing the output of the \”ls -l\” command while in the terminal and while working in the directory which contains the file or folder.

The permission in the command line is displayed as: _rwxrwxrwx 1 owner:group

User rights/Permissions
The first character that I marked with an underscore is the special permission flag that can vary.
The following set of three characters (rwx) is for the owner permissions.
The second set of three characters (rwx) is for the Group permissions.
The third set of three characters (rwx) is for the All Users permissions.
Following that grouping since the integer/number displays the number of hardlinks to the file.
The last piece is the Owner and Group assignment formatted as Owner:Group.

Modifying the Permissions

When in the command line, the permissions are edited by using the command chmod. You can assign the permissions explicitly or by using a binary reference as described below.
Explicitly Defining Permissions

To explicity define permissions you will need to reference the Permission Group and Permission Types.

The Permission Groups used are:

u – Owner
g – Group
o or a – All Users

The potential Assignment Operators are + (plus) and – (minus); these are used to tell the system whether to add or remove the specific permissions.

The Permission Types that are used are:

r – Read
w – Write
x – Execute

So for an example, lets say I have a file named file1 that currently has the permissions set to _rw_rw_rw, which means that the owner, group and all users have read and write permission. Now we want to remove the read and write permissions from the all users group.

To make this modification you would invoke the command: chmod a-rw file1
To add the permissions above you would invoke the command: chmod a+rw file1

As you can see, if you want to grant those permissions you would change the minus character to a plus to add those permissions.
Using Binary References to Set permissions

Now that you understand the permissions groups and types this one should feel natural. To set the permission using binary references you must first understand that the input is done by entering three integers/numbers.

A sample permission string would be chmod 640 file1, which means that the owner has read and write permissions, the group has read permissions, and all other user have no rights to the file.

The first number represents the Owner permission; the second represents the Group permissions; and the last number represents the permissions for all other users. The numbers are a binary representation of the rwx string.

r = 4
w = 2
x = 1

You add the numbers to get the integer/number representing the permissions you wish to set. You will need to include the binary permissions for each of the three permission groups.

So to set a file to permissions on file1 to read _rwxr_____, you would enter chmod 740 file1.

Owners and Groups

I have made several references to Owners and Groups above, but have not yet told you how to assign or change the Owner and Group assigned to a file or directory.

You use the chown command to change owner and group assignments, the syntax is simple chown owner:group filename, so to change the owner of file1 to user1 and the group to family you would enter chown user1:family file1.

Advanced Permissions

The special permissions flag can be marked with any of the following:

_ – no special permissions
d – directory
l – The file or directory is a symbolic link
s – This indicated the setuid/setgid permissions. This is not set displayed in the special permission part of the permissions display, but is represented as a s in the read portion of the owner or group permissions.
t – This indicates the sticky bit permissions. This is not set displayed in the special permission part of the permissions display, but is represented as a t in the executable portion of the all users permissions

Setuid/Setgid Special Permissions

The setuid/setguid permissions are used to tell the system to run an executable as the owner with the owner\’s permissions.

Be careful using setuid/setgid bits in permissions. If you incorrectly assign permissions to a file owned by root with the setuid/setgid bit set, then you can open your system to intrusion.

You can only assign the setuid/setgid bit by explicitly defining permissions. The character for the setuid/setguid bit is s.

So do set the setuid/setguid bit on file2.sh you would issue the command chmod g+s file2.sh.

Sticky Bit Special Permissions

The sticky bit can be very useful in shared environment because when it has been assigned to the permissions on a directory it sets it so only file owner can rename or delete the said file.

You can only assign the sticky bit by explicitly defining permissions. The character for the sticky bit is t.

To set the sticky bit on a directory named dir1 you would issue the command chmod +t dir1.
When Permissions Are Important

To some users of Mac- or Windows-based computers you don’t think about permissions, but those environments don’t focus so aggressively on user based rights on files unless you are in a corporate environment. But now you are running a Linux-based system and permission based security is simplified and can be easily used to restrict access as you please.

So I will show you some documents and folders that you want to focus on and show you how the optimal permissions should be set.

home directories – The users\’ home directories are important because you do not want other users to be able to view and modify the files in another user\’s documents of desktop. To remedy this you will want the directory to have the drwx______ (700) permissions, so lets say we want to enforce the correct permissions on the user user1\’s home directory that can be done by issuing the command chmod 700 /home/user1.
bootloader configuration files – If you decide to implement password to boot specific operating systems then you will want to remove read and write permissions from the configuration file from all users but root. To do you can change the permissions of the file to 700.
system and daemon configuration files – It is very important to restrict rights to system and daemon configuration files to restrict users from editing the contents, it may not be advisable to restrict read permissions, but restricting write permissions is a must. In these cases it may be best to modify the rights to 644.
firewall scripts – It may not always be necessary to block all users from reading the firewall file, but it is advisable to restrict the users from writing to the file. In this case the firewall script is run by the root user automatically on boot, so all other users need no rights, so you can assign the 700 permissions.

Other examples can be given, but this article is already very lengthy, so if you want to share other examples of needed restrictions please do so in the comments.
Comments Welcome

If you have anything to add or want to make a comment or correction please do so in the comments. I look forward to your feedback and wish you the best in your future with Linux-based systems.

The POSIX thread libraries are a standards based thread API for C/C++. It allows one to spawn a new concurrent process flow. It is most effective on multi-processor or multi-core systems where the process flow can be scheduled to run on another processor thus gaining speed through parallel or distributed processing. Threads require less overhead than “forking” or spawning a new process because the system does not initialize a new system virtual memory space and environment for the process. While most effective on a multiprocessor system, gains are also found on uniprocessor systems which exploit latency in I/O and other system functions which may halt process execution. (One thread may execute while another is waiting for I/O or some other system latency.) Parallel programming technologies such as MPI and PVM are used in a distributed computing environment while threads are limited to a single computer system. All threads within a process share the same address space. A thread is spawned by defining a function and its arguments which will be processed in the thread. The purpose of using the POSIX thread library in your software is to execute software faster.

Linux has the wait_queue_head_t data structure for implementing blocking I/O operations. A process that wants to wait for a condition can call either of the following wait_event_xxx() functions:

• wait_event()
• wait_event_interruptible()
• wait_event_timeout()
• wait_event_interruptible_timeout()
• wait_event_interruptible_exclusive()

The first four API’s will result in a non-exclusive wait. The last API will result in a exclusive wait.

There are some interesting facts to be noted about the corresponding wake_up_xxx() functions.

1. The wake_up(queue) and wake_up_interruptible(queue) functions will wake up all the non exclusive processes + one exclusive process waiting on the queue and whose wait condition is satisfied.
2. The wake_up_nr(queue, nr) and wake_up_interruptible(queue, nr) functions will wake up all the non exclusive processes + upto ‘nr’ exclusive processes waiting on the queue and whose wait conditions are satisfied.
3. The wake_up_all(queue) and wake_up_interruptible_all(queue) functions will wake up all the non exclusive processes + all exclusive processes waiting on the queue and whose wait conditions are satisfied.

Considering that we are not interested in ‘exclusive’ wait, let us analyze following two programs:

Program 1: Using wake_up() calls without delays

example_wake_up.c is a program that implements the following functionality:

• read() function that is blocked for data using the wait_event_interruptible() call.
• write() function that copies some data and then calls the wake_up_interruptible() call.

In order to test this program, perform the following operations:

• Insert the example_wake_up.ko module into the kernel using the insmod utility.
• Create a /dev/simple_char_dev entry using the mknod utility.
• Open a terminal and execute ‘cat /dev/simple_char_dev‘.
• Open another terminal and execute ‘cat /dev/simple_char_dev‘.
• Now in another terminal, execute the ‘echo “hello world for wake up testing” > /dev/simple_char_dev‘.
• You will notice that only one of the ‘cat’ programs will get the data. The other ‘cat’ program waits for data.

Program 2: Using wake_up() calls with delay

example_wake_up_delay.c is a program that implements the following functionality:

• read() function that is blocked for data using the wait_event_interruptible() call.
• write() function that copies some data and then calls the wake_up_interruptible() call.
• On wake up, the read() functions sleeps for one second before resetting the ‘wait condition’.

In order to test this program, perform the following operations:

• Insert the example_wake_up.ko module into the kernel using the insmod utility.
• Create a /dev/simple_char_dev entry using the mknod utility.
• Open a terminal and execute ‘cat /dev/simple_char_dev‘.
• Open another terminal and execute ‘cat /dev/simple_char_dev‘.
• Now in another terminal, execute the ‘echo “hello world for wake up testing” > /dev/simple_char_dev‘.
• You will notice that both the ‘cat’ programs will get the data.

Reason:

The above behavior is due the following facts about the wake_up() functions:

1. The ‘cat’ program is waiting in the read() function.
2. The ‘echo’ program provides some data and calls the wake_up() function.
3. As a result of the wake_up() function, a sleeping process can move to executing state and can get executed before the wake_up() function returns.
4. Without the delay, the first ‘cat’ program to wake up consumes the data and resets the condition.
5. When the wake_up() function continues to execute, it finds that the condition is already false. Hence it does not wake up any more processes.
6. With the delay before resetting the condition, the wake_up() function call will wake up all the processes.

API, an abbreviation of application program interface, is a set of routines, protocols, and tools for building software applications. The API specifies how software components should interact and are used when programming graphical user interface (GUI) components.  A good API makes it easier to develop a program by providing all the building blocks. A programmer then puts the blocks together.

#for the another synchroniztion technique.....COMPLETION....here in the end of the devwrite i make a call for the completion and in the devread in the starting i call wait_for_completion() and in the end i call complete()....it work fine for me.....

RCS file: application.c,v
Working file: application.c
head: 1.17
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 17;	selected revisions: 17
description:
this is the application program in the user space
open write and close is used
----------------------------
revision 1.17
date: 2014/06/02 12:09:20;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.16
date: 2014/05/30 07:19:57;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.15
date: 2014/05/30 07:09:07;  author: root;  state: Exp;  lines: +2 -2
*** empty log message ***
----------------------------
revision 1.14
date: 2014/05/29 06:06:43;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.13
date: 2014/05/29 06:05:10;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.12
date: 2014/05/29 05:44:00;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.11
date: 2014/05/29 05:43:01;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.10
date: 2014/05/29 05:38:44;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.9
date: 2014/05/29 05:37:02;  author: root;  state: Exp;  lines: +2 -2
*** empty log message ***
----------------------------
revision 1.8
date: 2014/05/26 11:19:01;  author: root;  state: Exp;  lines: +2 -2
seeking operation applied
apply SEEK_SET. and call lseek in application layer
----------------------------
revision 1.7
date: 2014/05/26 06:00:53;  author: root;  state: Exp;  lines: +10 -4
not open the node in RDWR mode because the node either open in the WR mode or in RD mode because its tbecause if we make it fullduplex then data get mingle.
----------------------------
revision 1.6
date: 2014/05/25 11:29:25;  author: root;  state: Exp;  lines: +11 -7
open the file in the O_RDWR mode then its capable to read and write from the files.
----------------------------
revision 1.5
date: 2014/05/24 11:49:01;  author: root;  state: Exp;  lines: +9 -9
*** empty log message ***
----------------------------
revision 1.4
date: 2014/05/24 11:35:56;  author: root;  state: Exp;  lines: +12 -12
close the fd for the writing then open it again in the read mode.
----------------------------
revision 1.3
date: 2014/05/24 09:07:54;  author: root;  state: Exp;  lines: +16 -2
close the fd for the write operation(important to close the fd otherwise use lseek)
then open in the read mode then read while using its file descriptor.
----------------------------
revision 1.2
date: 2014/05/24 07:49:26;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.1
date: 2014/05/24 07:17:20;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: devopen.c,v
Working file: devopen.c
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;	selected revisions: 3
description:
open the module in the kernel layer by passing the argument from the application layer of the open system call.
here we are not using the trim funciton.
----------------------------
revision 1.3
date: 2014/06/02 11:43:23;  author: root;  state: Exp;  lines: +5 -5
*** empty log message ***
----------------------------
revision 1.2
date: 2014/06/02 11:38:54;  author: root;  state: Exp;  lines: +7 -3
*** empty log message ***
----------------------------
revision 1.1
date: 2014/05/24 07:15:18;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: application2.c,v
Working file: application2.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
this is the application2.
here we are using the single node to exess the two application.
----------------------------
revision 1.1
date: 2014/05/30 07:55:15;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: cleanup.c,v
Working file: cleanup.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
this is used to remove and unregistered the module from the /proc/devices table.
----------------------------
revision 1.1
date: 2014/05/24 07:13:18;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: devread.c,v
Working file: devread.c
head: 1.21
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 21;	selected revisions: 21
description:
write the fuction for the read which is work in the kernel layer.
----------------------------
revision 1.21
date: 2014/06/03 12:48:40;  author: root;  state: Exp;  lines: +1 -0
give the wait_for_completion in the start...
and complete in the last....
work fine....in the different application accesing the same node....
----------------------------
revision 1.20
date: 2014/06/03 05:00:49;  author: root;  state: Exp;  lines: +3 -2
apply the completion in the devread.
----------------------------
revision 1.19
date: 2014/06/03 04:58:08;  author: root;  state: Exp;  lines: +2 -2
remove the semaphore...
----------------------------
revision 1.18
date: 2014/06/03 04:29:10;  author: root;  state: Exp;  lines: +1 -1
making up the semaphore above the returing...
----------------------------
revision 1.17
date: 2014/06/03 04:23:54;  author: root;  state: Exp;  lines: +3 -1
*** empty log message ***
----------------------------
revision 1.16
date: 2014/06/02 12:00:36;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.15
date: 2014/06/02 11:45:09;  author: root;  state: Exp;  lines: +2 -2
*** empty log message ***
----------------------------
revision 1.14
date: 2014/06/02 05:14:57;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.13
date: 2014/06/02 05:08:38;  author: root;  state: Exp;  lines: +2 -2
*** empty log message ***
----------------------------
revision 1.12
date: 2014/06/02 04:52:46;  author: root;  state: Exp;  lines: +6 -0
making down and up the semaphore by using the down_interruptible() and up() respectively.
----------------------------
revision 1.11
date: 2014/05/30 11:03:46;  author: root;  state: Exp;  lines: +1 -0
*** empty log message ***
----------------------------
revision 1.10
date: 2014/05/30 07:09:09;  author: root;  state: Exp;  lines: +13 -8
implement the SEEK_SET again.
and it work file
----------------------------
revision 1.9
date: 2014/05/26 11:19:45;  author: root;  state: Exp;  lines: +28 -9
draw logic for the seek operation.
----------------------------
revision 1.8
date: 2014/05/24 11:40:26;  author: root;  state: Exp;  lines: +9 -5
give the defination for the read function.
----------------------------
revision 1.7
date: 2014/05/24 10:34:09;  author: root;  state: Exp;  lines: +7 -2
*** empty log message ***
----------------------------
revision 1.6
date: 2014/05/24 09:28:15;  author: root;  state: Exp;  lines: +5 -5
*** empty log message ***
----------------------------
revision 1.5
date: 2014/05/24 09:26:24;  author: root;  state: Exp;  lines: +7 -7
*** empty log message ***
----------------------------
revision 1.4
date: 2014/05/24 09:21:09;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.3
date: 2014/05/24 09:19:17;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.2
date: 2014/05/24 09:16:07;  author: root;  state: Exp;  lines: +1 -0
make a access to the private data to the sculldev
----------------------------
revision 1.1
date: 2014/05/24 09:09:26;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: fileopr.h,v
Working file: fileopr.h
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;	selected revisions: 3
description:
used for the mapping purpose.
----------------------------
revision 1.3
date: 2014/05/25 11:30:20;  author: root;  state: Exp;  lines: +2 -1
*** empty log message ***
----------------------------
revision 1.2
date: 2014/05/24 09:09:56;  author: root;  state: Exp;  lines: +2 -1
do the mapping of read
----------------------------
revision 1.1
date: 2014/05/24 07:18:55;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: prototype.h,v
Working file: prototype.h
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;	selected revisions: 3
description:
declare the prototype.
----------------------------
revision 1.3
date: 2014/05/25 11:29:17;  author: root;  state: Exp;  lines: +1 -0
*** empty log message ***
----------------------------
revision 1.2
date: 2014/05/24 09:07:02;  author: root;  state: Exp;  lines: +2 -0
mention the prototype of the read call which is is fs.h header file and is in the struct file_operations {
----------------------------
revision 1.1
date: 2014/05/24 07:14:52;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: application3.c,v
Working file: application3.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
making the third application.
----------------------------
revision 1.1
date: 2014/05/30 09:20:55;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: declaration.h,v
Working file: declaration.h
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
define some macros which are freq	uently used in our program.
----------------------------
revision 1.1
date: 2014/05/24 07:14:06;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: devrelease.c,v
Working file: devrelease.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
for closeing the module
----------------------------
revision 1.1
date: 2014/05/24 07:16:45;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: header.h,v
Working file: header.h
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;	selected revisions: 3
description:
define macros and include header file in this and make a ScullDev and ScullQset structure in this.
----------------------------
revision 1.3
date: 2014/06/03 04:56:00;  author: root;  state: Exp;  lines: +2 -0
include the header file <linux.completion.h> for the completion...
----------------------------
revision 1.2
date: 2014/06/02 04:49:56;  author: root;  state: Exp;  lines: +3 -1
include the linux/semaphore.h header file for the semaphores.
----------------------------
revision 1.1
date: 2014/05/24 07:11:00;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: application4.c,v
Working file: application4.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
making the fourth application.
----------------------------
revision 1.1
date: 2014/05/30 09:21:09;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: devlseek.c,v
Working file: devlseek.c
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;	selected revisions: 3
description:
----------------------------
revision 1.3
date: 2014/06/02 07:22:38;  author: root;  state: Exp;  lines: +2 -2
*** empty log message ***
----------------------------
revision 1.2
date: 2014/05/30 07:09:37;  author: root;  state: Exp;  lines: +4 -2
*** empty log message ***
----------------------------
revision 1.1
date: 2014/05/25 11:30:12;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: devwrite.c,v
Working file: devwrite.c
head: 1.12
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 12;	selected revisions: 12
description:
used to write in the multiple quantum
multiple qset
then use copy_from_user.
very important file and hard too.
----------------------------
revision 1.12
date: 2014/06/03 12:48:15;  author: root;  state: Exp;  lines: +1 -0
given the complete call in the last...
----------------------------
revision 1.11
date: 2014/06/03 12:44:22;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.10
date: 2014/06/03 04:57:08;  author: root;  state: Exp;  lines: +4 -3
apply the wait_for_completion() same as the downing the semaphore...
apply the complete() same as the uping the semaphore...
----------------------------
revision 1.9
date: 2014/06/03 04:28:45;  author: root;  state: Exp;  lines: +2 -1
making up the semaphore above the returing.....
----------------------------
revision 1.8
date: 2014/06/03 04:21:25;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.7
date: 2014/06/02 12:11:54;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.6
date: 2014/06/02 11:45:08;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.5
date: 2014/06/02 05:14:55;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.4
date: 2014/06/02 04:51:17;  author: root;  state: Exp;  lines: +5 -0
making down and up the semaphore by using down_interruptible() and up() respectively
----------------------------
revision 1.3
date: 2014/05/25 09:31:31;  author: root;  state: Exp;  lines: +11 -4
use the loff and filep->f_pos to see the position of the pointer.
this loff and filep->f_pos could not be updated automatically so we make the updation.
----------------------------
revision 1.2
date: 2014/05/24 07:47:23;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.1
date: 2014/05/24 07:17:56;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: init.c,v
Working file: init.c
head: 1.4
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 4;	selected revisions: 4
description:
this is used to insert the module the register the module.
in this i dont use trim function.
----------------------------
revision 1.4
date: 2014/06/03 04:56:36;  author: root;  state: Exp;  lines: +2 -1
initilize the completion by init_completion above the cdev_add...
----------------------------
revision 1.3
date: 2014/06/02 11:38:52;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.2
date: 2014/06/02 04:50:25;  author: root;  state: Exp;  lines: +1 -0
initilize the binary semaphore before the cdev_add using the sema_init()
----------------------------
revision 1.1
date: 2014/05/24 07:12:20;  author: root;  state: Exp;
Initial revision
=============================================================================

#applying the semaphore....here i run the 4 application(open, write and read) from the single node.....and its working fine....


RCS file: application.c,v
Working file: application.c
head: 1.17
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 17;	selected revisions: 17
description:
this is the application program in the user space
open write and close is used
----------------------------
revision 1.17
date: 2014/06/02 12:09:20;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.16
date: 2014/05/30 07:19:57;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.15
date: 2014/05/30 07:09:07;  author: root;  state: Exp;  lines: +2 -2
*** empty log message ***
----------------------------
revision 1.14
date: 2014/05/29 06:06:43;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.13
date: 2014/05/29 06:05:10;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.12
date: 2014/05/29 05:44:00;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.11
date: 2014/05/29 05:43:01;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.10
date: 2014/05/29 05:38:44;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.9
date: 2014/05/29 05:37:02;  author: root;  state: Exp;  lines: +2 -2
*** empty log message ***
----------------------------
revision 1.8
date: 2014/05/26 11:19:01;  author: root;  state: Exp;  lines: +2 -2
seeking operation applied
apply SEEK_SET. and call lseek in application layer
----------------------------
revision 1.7
date: 2014/05/26 06:00:53;  author: root;  state: Exp;  lines: +10 -4
not open the node in RDWR mode because the node either open in the WR mode or in RD mode because its tbecause if we make it fullduplex then data get mingle.
----------------------------
revision 1.6
date: 2014/05/25 11:29:25;  author: root;  state: Exp;  lines: +11 -7
open the file in the O_RDWR mode then its capable to read and write from the files.
----------------------------
revision 1.5
date: 2014/05/24 11:49:01;  author: root;  state: Exp;  lines: +9 -9
*** empty log message ***
----------------------------
revision 1.4
date: 2014/05/24 11:35:56;  author: root;  state: Exp;  lines: +12 -12
close the fd for the writing then open it again in the read mode.
----------------------------
revision 1.3
date: 2014/05/24 09:07:54;  author: root;  state: Exp;  lines: +16 -2
close the fd for the write operation(important to close the fd otherwise use lseek)
then open in the read mode then read while using its file descriptor.
----------------------------
revision 1.2
date: 2014/05/24 07:49:26;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.1
date: 2014/05/24 07:17:20;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: devopen.c,v
Working file: devopen.c
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;	selected revisions: 3
description:
open the module in the kernel layer by passing the argument from the application layer of the open system call.
here we are not using the trim funciton.
----------------------------
revision 1.3
date: 2014/06/02 11:43:23;  author: root;  state: Exp;  lines: +5 -5
*** empty log message ***
----------------------------
revision 1.2
date: 2014/06/02 11:38:54;  author: root;  state: Exp;  lines: +7 -3
*** empty log message ***
----------------------------
revision 1.1
date: 2014/05/24 07:15:18;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: application2.c,v
Working file: application2.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
this is the application2.
here we are using the single node to exess the two application.
----------------------------
revision 1.1
date: 2014/05/30 07:55:15;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: cleanup.c,v
Working file: cleanup.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
this is used to remove and unregistered the module from the /proc/devices table.
----------------------------
revision 1.1
date: 2014/05/24 07:13:18;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: devread.c,v
Working file: devread.c
head: 1.18
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 18;	selected revisions: 18
description:
write the fuction for the read which is work in the kernel layer.
----------------------------
revision 1.18
date: 2014/06/03 04:29:10;  author: root;  state: Exp;  lines: +1 -1
making up the semaphore above the returing...
----------------------------
revision 1.17
date: 2014/06/03 04:23:54;  author: root;  state: Exp;  lines: +3 -1
*** empty log message ***
----------------------------
revision 1.16
date: 2014/06/02 12:00:36;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.15
date: 2014/06/02 11:45:09;  author: root;  state: Exp;  lines: +2 -2
*** empty log message ***
----------------------------
revision 1.14
date: 2014/06/02 05:14:57;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.13
date: 2014/06/02 05:08:38;  author: root;  state: Exp;  lines: +2 -2
*** empty log message ***
----------------------------
revision 1.12
date: 2014/06/02 04:52:46;  author: root;  state: Exp;  lines: +6 -0
making down and up the semaphore by using the down_interruptible() and up() respectively.
----------------------------
revision 1.11
date: 2014/05/30 11:03:46;  author: root;  state: Exp;  lines: +1 -0
*** empty log message ***
----------------------------
revision 1.10
date: 2014/05/30 07:09:09;  author: root;  state: Exp;  lines: +13 -8
implement the SEEK_SET again.
and it work file
----------------------------
revision 1.9
date: 2014/05/26 11:19:45;  author: root;  state: Exp;  lines: +28 -9
draw logic for the seek operation.
----------------------------
revision 1.8
date: 2014/05/24 11:40:26;  author: root;  state: Exp;  lines: +9 -5
give the defination for the read function.
----------------------------
revision 1.7
date: 2014/05/24 10:34:09;  author: root;  state: Exp;  lines: +7 -2
*** empty log message ***
----------------------------
revision 1.6
date: 2014/05/24 09:28:15;  author: root;  state: Exp;  lines: +5 -5
*** empty log message ***
----------------------------
revision 1.5
date: 2014/05/24 09:26:24;  author: root;  state: Exp;  lines: +7 -7
*** empty log message ***
----------------------------
revision 1.4
date: 2014/05/24 09:21:09;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.3
date: 2014/05/24 09:19:17;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.2
date: 2014/05/24 09:16:07;  author: root;  state: Exp;  lines: +1 -0
make a access to the private data to the sculldev
----------------------------
revision 1.1
date: 2014/05/24 09:09:26;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: fileopr.h,v
Working file: fileopr.h
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;	selected revisions: 3
description:
used for the mapping purpose.
----------------------------
revision 1.3
date: 2014/05/25 11:30:20;  author: root;  state: Exp;  lines: +2 -1
*** empty log message ***
----------------------------
revision 1.2
date: 2014/05/24 09:09:56;  author: root;  state: Exp;  lines: +2 -1
do the mapping of read
----------------------------
revision 1.1
date: 2014/05/24 07:18:55;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: prototype.h,v
Working file: prototype.h
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;	selected revisions: 3
description:
declare the prototype.
----------------------------
revision 1.3
date: 2014/05/25 11:29:17;  author: root;  state: Exp;  lines: +1 -0
*** empty log message ***
----------------------------
revision 1.2
date: 2014/05/24 09:07:02;  author: root;  state: Exp;  lines: +2 -0
mention the prototype of the read call which is is fs.h header file and is in the struct file_operations {
----------------------------
revision 1.1
date: 2014/05/24 07:14:52;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: application3.c,v
Working file: application3.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
making the third application.
----------------------------
revision 1.1
date: 2014/05/30 09:20:55;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: declaration.h,v
Working file: declaration.h
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
define some macros which are freq	uently used in our program.
----------------------------
revision 1.1
date: 2014/05/24 07:14:06;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: devrelease.c,v
Working file: devrelease.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
for closeing the module
----------------------------
revision 1.1
date: 2014/05/24 07:16:45;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: header.h,v
Working file: header.h
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;	selected revisions: 2
description:
define macros and include header file in this and make a ScullDev and ScullQset structure in this.
----------------------------
revision 1.2
date: 2014/06/02 04:49:56;  author: root;  state: Exp;  lines: +3 -1
include the linux/semaphore.h header file for the semaphores.
----------------------------
revision 1.1
date: 2014/05/24 07:11:00;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: application4.c,v
Working file: application4.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
making the fourth application.
----------------------------
revision 1.1
date: 2014/05/30 09:21:09;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: devlseek.c,v
Working file: devlseek.c
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;	selected revisions: 3
description:
----------------------------
revision 1.3
date: 2014/06/02 07:22:38;  author: root;  state: Exp;  lines: +2 -2
*** empty log message ***
----------------------------
revision 1.2
date: 2014/05/30 07:09:37;  author: root;  state: Exp;  lines: +4 -2
*** empty log message ***
----------------------------
revision 1.1
date: 2014/05/25 11:30:12;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: devwrite.c,v
Working file: devwrite.c
head: 1.9
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 9;	selected revisions: 9
description:
used to write in the multiple quantum
multiple qset
then use copy_from_user.
very important file and hard too.
----------------------------
revision 1.9
date: 2014/06/03 04:28:45;  author: root;  state: Exp;  lines: +2 -1
making up the semaphore above the returing.....
----------------------------
revision 1.8
date: 2014/06/03 04:21:25;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.7
date: 2014/06/02 12:11:54;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.6
date: 2014/06/02 11:45:08;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.5
date: 2014/06/02 05:14:55;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.4
date: 2014/06/02 04:51:17;  author: root;  state: Exp;  lines: +5 -0
making down and up the semaphore by using down_interruptible() and up() respectively
----------------------------
revision 1.3
date: 2014/05/25 09:31:31;  author: root;  state: Exp;  lines: +11 -4
use the loff and filep->f_pos to see the position of the pointer.
this loff and filep->f_pos could not be updated automatically so we make the updation.
----------------------------
revision 1.2
date: 2014/05/24 07:47:23;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.1
date: 2014/05/24 07:17:56;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: init.c,v
Working file: init.c
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;	selected revisions: 3
description:
this is used to insert the module the register the module.
in this i dont use trim function.
----------------------------
revision 1.3
date: 2014/06/02 11:38:52;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
----------------------------
revision 1.2
date: 2014/06/02 04:50:25;  author: root;  state: Exp;  lines: +1 -0
initilize the binary semaphore before the cdev_add using the sema_init()
----------------------------
revision 1.1
date: 2014/05/24 07:12:20;  author: root;  state: Exp;
Initial revision
=============================================================================

Python is an interpreted, object-oriented, high-level programming language with dynamic semantics. Its high-level built in data structures, combined with dynamic typing and dynamic binding, make it very attractive for Rapid Application Development, as well as for use as a scripting or glue language to connect existing components together. Python’s simple, easy to learn syntax emphasizes readability and therefore reduces the cost of program maintenance.

Often, programmers fall in love with Python because of the increased productivity it provides. Since there is no compilation step, the edit-test-debug cycle is incredibly fast. Debugging Python programs is easy: a bug or bad input will never cause a segmentation fault. Instead, when the interpreter discovers an error, it raises an exception. When the program doesn’t catch the exception, the interpreter prints a stack trace.