EmbLogic's Blog

difference b/w printf ,fprintf,snprintf and sprintf

printf, fprintf, sprintf, snprintf

Defined in header <stdio.h>
(1)
?int printf( const char          *format, … );?
 
?int printf( const char *restrict format, … );?
 
(2)
int fprintf( FILE          *stream, const char          *format, … );
 
int fprintf( FILE *restrict stream, const char *restrict format, … );
 
(3)
int sprintf( char          *buffer, const char          *format, … );
int sprintf( char *restrict buffer, const char *restrict format, … );
 
int snprintf( char *restrict buffer, int buf_size,
const char *restrict format, … );
(4)  

Loads the data from the given locations, converts them to character string equivalents and writes the results to a variety of sinks.

1) Writes the results to stdout.
2) Writes the results to a file stream stream.
3) Writes the results to a character string buffer.
4) Writes the results to a character string buffer. At most buf_size – 1 characters are written. The resulting character string will be terminated with a null character, unless buf_size is zero.
Posted in Uncategorized | Leave a comment

IPC USING FIFOS AND SEMAPHORES

******************************************************************************************

RCS file: server.c,v
Working file: server.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
Made a server file which takes request from client and forwards it to processing client
Then it takes result from processing client and gives the result back to the requesting client
the requesting client is given a pid to which server returns his answer.
=============================================================================

RCS file: script,v
Working file: script
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
this is the script file which is made to execute all the files at once.
total 5 fifos are used and one semaphore is used in the server.
=============================================================================

RCS file: client.c,v
Working file: client.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
The client sends the request using command line arguments
and at the finishing end it reads the result back from the server.
=============================================================================

RCS file: add.c,v
Working file: add.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
processing client adds the two files after reading values from server
and writes back the result to the server
=============================================================================

RCS file: sub.c,v
Working file: sub.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
thats another processing client
it subtracts the two values
=============================================================================

RCS file: mul.c,v
Working file: mul.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
its function is also same as other processing clients but it multiplies them.
=============================================================================

Posted in Uncategorized | Leave a comment

Character Driver VS Block Driver

There are two main types of devices under all systems, character and block devices. Character devices are those for which no buffering is performed, and block devices are those which are accessed through a cache. Block devices must be random access, but character devices are not required to be, though some are. Filesystems can only be mounted if they are on block devices.

Character devices are read from and written to with two function: foo_read() and foo_write(). The read() and write() calls do not return until the operation is complete. By contrast, block devices do not even implement the read() and write() functions, and instead have a function which has historically been called the “strategy routine.” Reads and writes are done through the buffer cache mechanism by the generic functions bread(), breada(), and bwrite(). These functions go through the buffer cache, and so may or may not actually call the strategy routine, depending on whether or not the block requested is in the buffer cache (for reads) or on whether or not the buffer cache is full (for writes).

A request may be asyncronous: breada() can request the strategy routine to schedule reads that have not been asked for, and to do it asyncronously, in the background, in the hopes that they will be needed later.

The sources for character devices are kept in …/kernel/chr_drv/, and the sources for block devices are kept in …/kernel/blk_drv/. They have similar interfaces, and are very much alike, except for reading and writing. Because of the difference in reading and writing, initialization is different, as block devices have to register a strategy routine, which is registered in a different way than the foo_read() and foo_write()routines of a character device driver.

Posted in Device Drivers | Leave a comment

IPC USING FIFOS AND SEMAPHORES.

HEADER FILE ***************************************************************

RCS file: ./header.h,v
Working file: ./header.h
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
Included “stdio.h” , “stdlib.h”, “unistd.h”, “linux/sem.h”, “fcntl.h”, and “signal.h”.
Declaration of the structure “package”, with members – op1(int), op2(int), arth(char), pid(pid_t), result(int).
—————————-
revision 1.1
date: 2014/08/12 10:59:58;  author: root;  state: Exp;
Initial revision
=============================================================================

SERVER PROGRAM **************************************************************

RCS file: ./server.c,v
Working file: ./server.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
This is the server program .
Declared 3 fifos , 1 for client routines and 2 for processing routines.
fork children of the server. number of children is equal to number of clients.
Each child links with respective clients and reads the data to be processed.
then the forked child send the data to the processing client .
gets the result back, and sends it to the client.
semaphores are used wherever fifos are shared.
—————————-
revision 1.1
date: 2014/08/12 11:18:11;  author: root;  state: Exp;
Initial revision
=============================================================================

CLIENT PROGRAM **************************************************************

RCS file: ./client.c,v
Working file: ./client.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
This is the client program.
It writes the values to b written into the fifo for server to read it.
this it pauses using pause() system call.
when the server has the answer it prompts the client by sending it a signal using kill system call.
the respective client whose pid is present in the kill() is resumed , reads the result and displays it.
—————————-
revision 1.1
date: 2014/08/12 11:21:10;  author: root;  state: Exp;
Initial revision
=============================================================================

ADD PROCESSING CLIENT *******************************************************

RCS file: ./add.c,v
Working file: ./add.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
This is the addition processing client.
it reads the values from server using one fifo.
each processing client is using a common fifo to write back the result to server.
—————————-
revision 1.1
date: 2014/08/12 11:23:54;  author: root;  state: Exp;
Initial revision
=============================================================================

SUBTRACT PROCESSING CLIENT **************************************************

RCS file: ./subtract.c,v
Working file: ./subtract.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
This is the subtracting client.
it reads the values from server using one fifo.
each processing client is using a common fifo to write back the result to server.
—————————-

Posted in Uncategorized | Leave a comment

IPC (Using FIFOS , without semaphores)

1
2 RCS file: server.c,v
3 Working file: server.c
4 head: 1.5
5 branch:
6 locks: strict
7 access list:
8 symbolic names:
9 keyword substitution: kv
10 total revisions: 5; selected revisions: 5
11 description:
12 Implementing ipc using fifos
13 —————————-
14 revision 1.5
15 date: 2014/08/12 05:37:54; author: root; state: Exp; lines: +13 -4
16 Completed the implementation the IPC(client-server) using FIFOS.
17 No synchronisation mechanism used.
18 Issues :
19 If more than one client send the same type of request, then the server becomes less reliable
20 —————————-
21 revision 1.4
22 date: 2014/08/10 18:08:52; author: root; state: Exp; lines: +4 -0
23 Upto here :
24 1. the req client 1 successfully write the structure into the fifo, which is successfully read by the server, and displayed.
25 2. the structure read by the server is now to be written in the fifo of the processing client.
26 3. next target : to successfully write the structure to the fifo of pc.
27 —————————-
28 revision 1.3
29 date: 2014/08/10 18:00:40; author: root; state: Exp; lines: +77 -17
30 Trying to read the req fifo of a client by the server.
31 —————————-
32 revision 1.2
33 date: 2014/08/10 16:45:36; author: root; state: Exp; lines: +1 -1
34 Implemented _create_fifos() function that enables the server to create child readers for reading each of the request fifos.
“log_file” 39L, 1544C 1,0-1 Top

Posted in Project 03: Client Server Communication using Linux and IPC | Leave a comment

IPC (USING PIPES, WITHOUT SYNCHRNISATION)

1
2 RCS file: server.c,v
3 Working file: server.c
4 head: 1.5
5 branch:
6 locks: strict
7 access list:
8 symbolic names:
9 keyword substitution: kv
10 total revisions: 5; selected revisions: 5
11 description:
12 Implementing ipc using pipes.
13 —————————-
14 revision 1.5
15 date: 2014/08/12 05:43:09; author: root; state: Exp; lines: +77 -9
16 Completed the IPC mechanism using pipes, without synchronisation.
17 Server uses wait() 2 times.
18 —————————-
19 revision 1.4
20 date: 2014/08/06 18:18:14; author: root; state: Exp; lines: +29 -1
21 Completed the implementation of the server for all the three clients.
22 Flow of contorl as expected.
23 No issues as of now.
24 Testing ot be continued.
25 IPC using pipes completed for three processes.
26 —————————-
27 revision 1.3
28 date: 2014/08/06 15:51:31; author: root; state: Exp; lines: +83 -8
29 Implementation complete for a single client.
30 Every thing works fine.
31 Have to replicate it for 3 and then 30 clients.
32 —————————-
33 revision 1.2
34 date: 2014/08/06 14:12:57; author: root; state: Exp; lines: +130 -1
1,0-1 Top

Posted in Project 03: Client Server Communication using Linux and IPC | Leave a comment

IPC using PIPES — logfile

RCS file: ./server1.c,v
Working file: ./server1.c
head: 1.4
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 4;    selected revisions: 4
description:
Server for server-client application.
—————————-
revision 1.4
date: 2014/08/11 06:59:46;  author: root;  state: Exp;  lines: +92 -107
Replaced sleep statements with waitpid.
—————————-
revision 1.3
date: 2014/08/10 12:23:10;  author: root;  state: Exp;  lines: +98 -10
Server for 3 different clients with dedicated pipes completed.
—————————-
revision 1.2
date: 2014/08/10 08:55:31;  author: root;  state: Exp;  lines: +20 -4
received data from 3 clients.
—————————-
revision 1.1
date: 2014/08/10 08:39:26;  author: root;  state: Exp;
Initial revision
=============================================================================

Posted in Project 03: Client Server Communication using Linux and IPC | Leave a comment

rcs of sever program in IPC……

RCS file: ./server.c,v
3 Working file: ./server.c
4 head: 1.200
5 branch:
6 locks: strict
7 access list:
8 symbolic names:
9 keyword substitution: kv
10 total revisions: 200;   selected revisions: 200
11 description:
12 This is the server program
13 —————————-
14 revision 1.200
15 date: 2014/08/07 17:16:57;  author: root;  state: Exp;  lines: +1 -1
16 *** empty log message ***
17 —————————-
18 revision 1.199
19 date: 2014/08/07 17:14:26;  author: root;  state: Exp;  lines: +1 -1
20 *** empty log message ***
21 —————————-
22 revision 1.198
23 date: 2014/08/07 13:26:41;  author: root;  state: Exp;  lines: +1 -1
24 *** empty log message ***
25 —————————-
26 revision 1.197
27 date: 2014/08/07 13:25:37;  author: root;  state: Exp;  lines: +1 -8
28 *** empty log message ***
29 —————————-
30 revision 1.196
31 date: 2014/08/07 13:24:14;  author: root;  state: Exp;  lines: +6 -10
32 *** empty log message ***
33 —————————-
34 revision 1.195
date: 2014/08/07 13:16:16;  author: root;  state: Exp;  lines: +4 -10
36 *** empty log message ***
37 —————————-
38 revision 1.194
39 date: 2014/08/07 13:13:41;  author: root;  state: Exp;  lines: +4 -1
40 *** empty log message ***
41 —————————-
42 revision 1.193
43 date: 2014/08/07 13:11:46;  author: root;  state: Exp;  lines: +1 -1
44 *** empty log message ***
45 —————————-
46 revision 1.192
47 date: 2014/08/07 13:10:45;  author: root;  state: Exp;  lines: +2 -2
48 *** empty log message ***
49 —————————-
50 revision 1.191
51 date: 2014/08/07 13:06:29;  author: root;  state: Exp;  lines: +1 -1
52 *** empty log message ***
53 —————————-
54 revision 1.190
55 date: 2014/08/07 13:05:32;  author: root;  state: Exp;  lines: +5 -1
revision 1.189
59 date: 2014/08/07 11:47:19;  author: root;  state: Exp;  lines: +3 -9
60 *** empty log message ***
61 —————————-
62 revision 1.188
63 date: 2014/08/07 11:44:38;  author: root;  state: Exp;  lines: +3 -2
64 *** empty log message ***
65 —————————-
66 revision 1.187
67 date: 2014/08/07 11:42:51;  author: root;  state: Exp;  lines: +3 -2
68 *** empty log message ***
69 —————————-
70 revision 1.186
71 date: 2014/08/07 11:41:09;  author: root;  state: Exp;  lines: +5 -1
72 *** empty log message ***
73 —————————-
74 revision 1.185
75 date: 2014/08/07 11:39:10;  author: root;  state: Exp;  lines: +1 -1
76 *** empty log message ***
77 —————————-
78 revision 1.184
79 date: 2014/08/07 11:38:44;  author: root;  state: Exp;  lines: +1 -1
*** empty log message ***
81 —————————-
82 revision 1.183
83 date: 2014/08/07 11:36:52;  author: root;  state: Exp;  lines: +2 -1
84 *** empty log message ***
85 —————————-
86 revision 1.182
87 date: 2014/08/07 11:35:30;  author: root;  state: Exp;  lines: +1 -1
88 *** empty log message ***
89 —————————-
90 revision 1.181
91 date: 2014/08/07 11:34:31;  author: root;  state: Exp;  lines: +1 -1
92 *** empty log message ***
93 —————————-
94 revision 1.180
95 date: 2014/08/07 11:34:07;  author: root;  state: Exp;  lines: +1 -1
96 *** empty log message ***
97 —————————-
98 revision 1.179
99 date: 2014/08/07 11:33:36;  author: root;  state: Exp;  lines: +1 -1
100 *** empty log message ***
101 —————————-
102 revision 1.178
.

.

.

.

.

.

.

.

.

.

.

.

.

.

.
evision 1.5
795 date: 2014/08/04 17:46:40;  author: root;  state: Exp;  lines: +1 -1
796 *** empty log message ***
797 —————————-
798 revision 1.4
799 date: 2014/08/04 17:43:32;  author: root;  state: Exp;  lines: +2 -2
800 *** empty log message ***
801 —————————-
802 revision 1.3
803 date: 2014/08/04 17:40:14;  author: root;  state: Exp;  lines: +1 -1
804 *** empty log message ***
805 —————————-
806 revision 1.2
807 date: 2014/08/04 17:39:37;  author: root;  state: Exp;  lines: +2 -2
808 *** empty log message ***
809 —————————-
810 revision 1.1
811 date: 2014/08/04 17:37:48;  author: root;  state: Exp;
812 Initial revision
813 ============================================================================

Posted in Project 03: Client Server Communication using Linux and IPC | Leave a comment

IPC(Inter Process Communication) using pipes

RCS file: server.c,v
Working file: server.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
made the server to perform three operations
but can create file descriptors upto 100
=============================================================================

RCS file: add.c,v
Working file: add.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
made the file for adding
will be exexuted from server through the pipe.
=============================================================================

RCS file: sub.c,v
Working file: sub.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
made the file for subtracting
will be executed from server through the pipe
=============================================================================

RCS file: mul.c,v
Working file: mul.c
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
similar function except this will multiply.
=============================================================================

RCS file: header.h,v
Working file: header.h
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
made the header file
included 5 header files
=============================================================================

Posted in Uncategorized | Leave a comment

linklist all done !

RCS file: ./linklist1.c,v
Working file: ./linklist1.c
head: 1.5
branch:
locks: strict
root: 1.5
access list:
symbolic names:
keyword substitution: kv
total revisions: 5; selected revisions: 5
description:
make a struct for linklist and defined three pointers start,prev,end .
data store more than 10 bytes in single node.
create multiple node.
—————————-
revision 1.5 locked by: root;
date: 2014/08/05 07:48:30; author: root; state: Exp; lines: +75 -4
all processes of linklist like insert any point any node, delete any node from key position is done.
—————————-
revision 1.4
date: 2014/07/24 18:30:09; author: root; state: Exp; lines: +31 -0
dispay all node , insert node at key position where you want.
—————————-
revision 1.3
date: 2014/07/21 16:57:35; author: root; state: Exp; lines: +130 -18
===============================ENTER 1 : FOR CREATE NODE===============================\n”);
139 printf(” ===============================ENTER 2 : FOR CREATE DATA===============================\n”);
140 printf(” ===============================ENTER 3 : FOR GIVE DATA TO NODE=========================\n”);
141 printf(” ===============================ENTER 4 : FOR CREATE NEW NODE===========================\n”);
142 printf(” ===============================ENTER 5 : FOR DISPLAY NODES=============================\n”);
143 printf(” ===============================ENTER 6 : FOR DELETE NODE FROM LAST=====================\n”);
144 printf(” ===============================ENTER 7 : FOR DELETE NODE FROM BEGNING==================\n”);
145 printf(” ===============================ENTER 8 : FOR INSERT NODE FROM BEGNING==================\n”);
—————————-
revision 1.2
date: 2014/07/15 11:15:21; author: root; state: Exp; lines: +33 -10
create linklist in loop and delete in while according to choice.
—————————-
revision 1.1
date: 2014/07/15 04:51:16; author: root; state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

rlog /client ,server model using ipc/

RCS file: server.c,v
Working file: server.c
head: 1.17
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 17; selected revisions: 17
description:
data form the all the clients have been taken successfully
server calls the client by creating child process
—————————-
revision 1.17
date: 2014/08/03 17:39:11; author: root; state: Exp; lines: +1 -1
*** empty log message ***
—————————-
revision 1.16
date: 2014/08/03 17:37:21; author: root; state: Exp; lines: +2 -2
final changes
—————————-
revision 1.15
date: 2014/08/03 17:31:14; author: root; state: Exp; lines: +21 -19
*** empty log message ***
—————————-
revision 1.14
date: 2014/08/03 17:24:24; author: root; state: Exp; lines: +0 -9
*** empty log message ***
—————————-
revision 1.13
date: 2014/08/03 17:20:45; author: root; state: Exp; lines: +33 -12
some final changes
—————————-
revision 1.12
date: 2014/08/03 16:31:00; author: root; state: Exp; lines: +8 -7
all the operation processes added
—————————-
revision 1.11
date: 2014/08/03 10:41:13; author: root; state: Exp; lines: +12 -7
solution from the operation process recieved successfull
—————————-
revision 1.10
date: 2014/08/03 09:58:01; author: root; state: Exp; lines: +7 -4
*** empty log message ***
—————————-
revision 1.9
date: 2014/08/03 09:49:30; author: root; state: Exp; lines: +3 -2
*** empty log message ***
—————————-
revision 1.8
date: 2014/08/03 09:13:44; author: root; state: Exp; lines: +3 -2
1
2
s
—————————-
revision 1.7
date: 2014/08/03 09:11:22; author: root; state: Exp; lines: +46 -3
*** empty log message ***
—————————-
revision 1.6
date: 2014/08/03 08:46:27; author: root; state: Exp; lines: +2 -54
changes
—————————-
revision 1.5
date: 2014/08/03 08:43:04; author: root; state: Exp; lines: +6 -2
every client is called using function
—————————-
revision 1.4
date: 2014/08/03 08:40:59; author: root; state: Exp; lines: +2 -1
*** empty log message ***
—————————-
revision 1.3
date: 2014/08/03 08:39:02; author: root; state: Exp; lines: +2 -0
some changes
—————————-
revision 1.2
date: 2014/08/03 08:36:41; author: root; state: Exp; lines: +19 -7
function for reading data created
—————————-
revision 1.1
date: 2014/08/03 07:36:47; author: root; state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

rlog / link list / complete

RCS file: ll_comp.c,v
Working file: ll_comp.c
head: 1.25
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 25; selected revisions: 25
description:
creatin , insertion at the end is completed
—————————-
revision 1.25
date: 2014/07/30 14:23:28; author: root; state: Exp; lines: +8 -10
*** empty log message ***
—————————-
revision 1.24
date: 2014/07/25 07:45:12; author: root; state: Exp; lines: +9 -5
some changes
—————————-
revision 1.23
date: 2014/07/25 07:35:25; author: root; state: Exp; lines: +51 -17
deletion at the key is added
—————————-
revision 1.22
date: 2014/07/25 06:51:48; author: root; state: Exp; lines: +1 -1
changes
—————————-
revision 1.21
date: 2014/07/25 06:27:17; author: root; state: Exp; lines: +11 -6
*** empty log message ***
—————————-
revision 1.20
date: 2014/07/24 13:59:41; author: root; state: Exp; lines: +24 -3
deletion at the n is added
—————————-
revision 1.19
date: 2014/07/24 13:46:29; author: root; state: Exp; lines: +17 -2
deletion from the end is executed
—————————-
revision 1.18
date: 2014/07/24 13:09:56; author: root; state: Exp; lines: +60 -8
delete from the begning added
—————————-
revision 1.17
date: 2014/07/24 12:16:04; author: root; state: Exp; lines: +5 -13
final changes fir insertion
—————————-
revision 1.16
date: 2014/07/24 11:55:24; author: root; state: Exp; lines: +5 -3
*** empty log message ***
—————————-
revision 1.15
date: 2014/07/24 11:52:21; author: root; state: Exp; lines: +2 -1
final changes
—————————-
revision 1.14
date: 2014/07/24 11:49:07; author: root; state: Exp; lines: +1 -1
*** empty log message ***
—————————-
revision 1.13
date: 2014/07/24 11:47:38; author: root; state: Exp; lines: +2 -1
*** empty log message ***
—————————-
revision 1.12
date: 2014/07/24 11:45:29; author: root; state: Exp; lines: +9 -1
*** empty log message ***
—————————-
revision 1.11
date: 2014/07/24 11:39:08; author: root; state: Exp; lines: +3 -2
*** empty log message ***
—————————-
revision 1.10
date: 2014/07/24 11:14:47; author: root; state: Exp; lines: +17 -7
changes
—————————-
revision 1.9
date: 2014/07/24 11:07:42; author: root; state: Exp; lines: +19 -0
enter at the key funtion added
—————————-
revision 1.8
date: 2014/07/24 10:49:15; author: root; state: Exp; lines: +5 -4
error repaired
—————————-
revision 1.7
date: 2014/07/24 10:42:55; author: root; state: Exp; lines: +1 -1
*** empty log message ***
—————————-
revision 1.6
date: 2014/07/24 10:41:00; author: root; state: Exp; lines: +1 -0
insert at the n added
—————————-
revision 1.5
date: 2014/07/24 10:39:52; author: root; state: Exp; lines: +18 -2
*** empty log message ***
—————————-
revision 1.4
date: 2014/07/24 10:13:02; author: root; state: Exp; lines: +1 -1
*** empty log message ***
—————————-
revision 1.3
date: 2014/07/24 10:12:26; author: root; state: Exp; lines: +4 -3
*** empty log message ***
—————————-
revision 1.2
date: 2014/07/24 10:10:48; author: root; state: Exp; lines: +18 -8
insert at the begning added
—————————-
revision 1.1
date: 2014/07/24 09:43:51; author: root; state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

Stack completed(using link list)

RCS file: ./stack.c,v
Working file: ./stack.c
head: 1.19
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 19; selected revisions: 19
description:
implemented basic program for stack.
gave defination for get_choice().
—————————-
revision 1.19
date: 2014/07/27 15:43:57; author: root; state: Exp; lines: +28 -27
implemented condition for deleting 1′st node in pop_stack().
stack using link list completed.
—————————-
revision 1.18
date: 2014/07/25 03:43:22; author: root; state: Exp; lines: +2 -2
*** empty log message ***
—————————-
revision 1.17
date: 2014/07/24 13:03:38; author: root; state: Exp; lines: +16 -4
implemented conditions for stack_already_created,first_create_stack().
—————————-
revision 1.16
date: 2014/07/24 12:47:16; author: root; state: Exp; lines: +25 -11
implemented conditions for making stack empty in func pop_stack().
—————————-
revision 1.15
date: 2014/07/24 09:10:08; author: root; state: Exp; lines: +20 -1
gave defination for function pop_stack().
—————————-
revision 1.14
date: 2014/07/24 08:34:07; author: root; state: Exp; lines: +5 -2
*** empty log message ***
—————————-
revision 1.13
date: 2014/07/24 08:28:40; author: root; state: Exp; lines: +9 -1
gave defination for function display_stack().
—————————-
revision 1.12
date: 2014/07/24 08:20:19; author: root; state: Exp; lines: +6 -6
*** empty log message ***
—————————-
revision 1.11
date: 2014/07/24 08:13:08; author: root; state: Exp; lines: +1 -1
in push_stack(), changed flag to top.
—————————-
revision 1.10
date: 2014/07/24 08:10:05; author: root; state: Exp; lines: +29 -3
gave defination for function push_stack().
returned start from push_stack() & operation() to main().
—————————-
revision 1.9
date: 2014/07/24 07:38:35; author: root; state: Exp; lines: +11 -0
gave defination for function create_node().
—————————-
revision 1.8
date: 2014/07/24 07:24:44; author: root; state: Exp; lines: +1 -1
*** empty log message ***
—————————-
revision 1.7
date: 2014/07/24 07:23:46; author: root; state: Exp; lines: +4 -0
*** empty log message ***
—————————-
revision 1.6
date: 2014/07/24 07:21:25; author: root; state: Exp; lines: +1 -1
implemented defination for function create_stack().
—————————-
revision 1.5
date: 2014/07/24 07:02:00; author: root; state: Exp; lines: +2 -2
*** empty log message ***
—————————-
revision 1.4
date: 2014/07/24 07:01:24; author: root; state: Exp; lines: +2 -2
*** empty log message ***
—————————-
revision 1.3
date: 2014/07/24 06:57:11; author: root; state: Exp; lines: +1 -1
*** empty log message ***
—————————-
revision 1.2
date: 2014/07/24 06:55:05; author: root; state: Exp; lines: +16 -0
gave defination for function operation().
—————————-
revision 1.1
date: 2014/07/24 05:48:18; author: root; state: Exp;
Initial revision
=============================================================================

Posted in Data Structures with C | Leave a comment

INTER PROCESS COMMUNICATION USING PIPES.(client server based)

INTER PROCESS COMMUNICATION USING PIPES.

RCS file: header.h,v
Working file: header.h
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
Included stdio.h.
and fcntl.h.
,sys/types.h, stdlib.h, unistd.h.
—————————-
revision 1.1
date: 2014/08/02 03:44:56;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: pipes.c,v
Working file: pipes.c
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 2
description:
Main function of the inter process communication program.
calling the client function to generate clients.
—————————-
revision 1.2
date: 2014/08/02 04:57:36;  author: root;  state: Exp;  lines: +17 -1
forking three independent clients.
with different values.
—————————-
revision 1.1
date: 2014/08/02 03:44:56;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: define.c,v
Working file: define.c
head: 1.4
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 4;    selected revisions: 4
description:
definations of functions client(),
operator_l()–services the client ,forks and execls appropriate service program.
—————————-
revision 1.4
date: 2014/08/02 05:14:43;  author: root;  state: Exp;  lines: +5 -3
client was showing first operand as result.
fixed it.
—————————-
revision 1.3
date: 2014/08/02 04:57:02;  author: root;  state: Exp;  lines: +9 -3
added fcntl.h.
—————————-
revision 1.2
date: 2014/08/02 03:47:28;  author: root;  state: Exp;  lines: +0 -24
*** empty log message ***
—————————-
revision 1.1
date: 2014/08/02 03:44:56;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: client.c,v
Working file: client.c
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;    selected revisions: 3
description:
This is the client program which requests the server to
perform given operation on the two operands.
—————————-
revision 1.3
date: 2014/08/02 05:15:33;  author: root;  state: Exp;  lines: +2 -2
now the client waits for the server to get results.
—————————-
revision 1.2
date: 2014/08/02 04:58:16;  author: root;  state: Exp;  lines: +6 -3
now the client waits and reads the result from the server.
—————————-
revision 1.1
date: 2014/08/02 03:44:56;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: add.c,v
Working file: add.c
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 2
description:
The program to add two numbers given by the client program.
writes the result back to the server.
—————————-
revision 1.2
date: 2014/08/02 04:59:01;  author: root;  state: Exp;  lines: +1 -2
*** empty log message ***
—————————-
revision 1.1
date: 2014/08/02 03:44:56;  author: root;  state: Exp;
Initial revision
=============================================================================
RCS file: subtract.c,v
Working file: subtract.c
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 2
description:
The program to subtract two numbers given by the client program.
writes the result back to server.
—————————-
revision 1.2
date: 2014/08/02 04:59:05;  author: root;  state: Exp;  lines: +1 -2
*** empty log message ***
—————————-
revision 1.1
date: 2014/08/02 03:44:56;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: multiply.c,v
Working file: multiply.c
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 2
description:
The program to multiply two numbers given by the client program.
writes the result back to server.
—————————-
revision 1.2
date: 2014/08/02 04:59:06;  author: root;  state: Exp;  lines: +1 -2
*** empty log message ***
—————————-
revision 1.1
date: 2014/08/02 03:44:56;  author: root;  state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

about proc, proc_create,proc_entry

The proc file system is an interface between the kernel and the userspace. Every entry in the proc file system provides some information from the kernel.
For eg:
The entry “meminfo” gives the details of the memory being used in the system.
To read the data in this entry just run
cat /proc/meminfo

Similarly the “modules” entry gives details of all the modules that are currently a part of the kernel.
cat /proc/modules

The proc file system is also very useful when we want to debug a kernel module. While debugging we might want to know the values of various variables in the module or may be the data that module is handling. In such situations we can create a proc entry for our selves and dump what ever data we want to look into in the entry.
We will be using the same example character driver that we created in the previous post to create the proc entry.

The proc entry can also be used to pass data to the kernel by writing into the kernel, so there can be two kinds of proc entries
An entry that only reads data from the kernel space
An entry that reads as well as writes data into and from kernel space.

We will start by creating a proc entry for only reading first and then move to a a proc entry for write.
Creating proc entry:

Kernel provides the following functions to create a proc entry

create_proc_read_entry()
create_proc_entry()

Both of these functions are defined in the file linux/proc_fs.h.

The create_proc_entry is a generic function that allows to create both read as well as write entries.
create_proc_read_entry is a function specific to create only read entries.

Its possible that most of the proc entries are created to read data from the kernel space that is why the kernel developers have provided a direct function to create a read proc entry.

We will first use the create_proc_read_entry to create our entry and then look into create_proc_entry.

The proc entries are basically based on the structure “proc_dir_entry”. Meaning every proc entry that gets created is represented by a structure of the kind
“proc_dir_entry” by the kernel.
The structure “proc_dir_entry” looks as follows in 2.6.33-21

The prototype of the function create_proc_read_entry is

struct proc_dir_entry *create_proc_read_entry(const char *name,
mode_t mode, struct proc_dir_entry *base,
read_proc_t *read_proc, void * data)

name : This the name by which entry will be created under the proc file system.
for eg: if we pass “first_proc_entry” , then it will create a file by the name
first_proc_entry under the /proc directory.
mode : mode sets the permissions for the entry created, if 0 is passed it takes
system default settings
base : Base is the base directory in which the entry should be created, this is
useful when you want to create a proc entry under a sub folder in /proc. If
you pass NULL it will create it under /proc by default
read_proc: read_proc is a pointer to the function that should be called every time
the proc entry is read. The function should be implemented in the
driver. It is this functions which we will use to display what ever data
we want to display to the user.
data : This is not used by the kernel, but is passed as it is to the read_proc
function. The data is used by the driver writer to pass any private data
that has to be passed to the read_proc function. It can be passed as NULL
if no data has to be passed.

Once a module gets registered with the kernel, the corresponding proc entry should also be created. So the call to the function create_read_proc_entry is included in the “init” function of the driver.

Removing a proc entry:

When a module is removed from the kernel, it should also remove any proc entries it created. The function that enables the removal of proc entry is “remove_proc_entry” which has the following prototype
void remove_proc_entry(const char *name, struct proc_dir_entry *parent);

name: Name of the proc entry that has to be removed.
parent: In case the proc entry lies in a subdirectory under the proc filesystem, we
can pass the subdirectories here.

With this introduction to proc filesystem and the corresponding function calls that will allow us to create the entries we can start writing the code to create our first proc entry.

Posted in Uncategorized | Leave a comment