description:
this progra is three client and three processing with pipe using
—————————-
revision 1.1
date: 2014/05/17 07:12:46; author: root; state: Exp;
Initial revision
=============================================================================
head 1.2;
access;
symbols;
locks
root:1.2; strict;
comment @ * @;
1.2
date 2014.05.15.11.19.59; author root; state Exp;
branches;
next 1.1;
1.1
date 2014.05.14.09.42.00; author root; state Exp;
branches;
next ;
desc
@server iof fifo is.
@
1.2
log
@*** empty log message ***
@
text
@#include”header.h”
int main()
{
struct data data1;
int len,len1,ret,ret1,count,mul,fd,fd1,fd2,fd3,result;
ret=access(“raushan”,F_OK);
if(ret==-1)
{
ret=mkfifo(“raushan”,777);
}
fd=open(“raushan”,O_RDONLY);
if(fd<0)
{
perror(“\n open is failure”);
goto OUT;
}
len=sizeof(struct data);
count=read(fd,&data1,len);
printf(“\n bytes is %d %d %d %c”,count,data1.a,data1.b,data1.opr);
ret=access(“raushan1″,F_OK);
if(ret==-1)
{
ret=mkfifo(“raushan1″,777);
}
fd1=open(“raushan1″,O_WRONLY);
if(fd1<0)
{
perror(“\n open is failure”);
goto OUT;
}
len1=sizeof(struct data);
count=write(fd1,&data1,len1);
printf(“\n bytes is %d”,count);
fd1=open(“raushan1″,O_RDONLY);
len=sizeof(result);
count=read(fd1,&result,len);
printf(“\n result=%d”,result);
close(fd1);
fd=open(“raushan”,O_WRONLY);
len=sizeof(result);
count=write(fd,&result,len);
printf(“\n result=%d”,result);
ret=access(“raushan2″,F_OK);
if(ret==-1)
{
ret=mkfifo(“raushan2″,777);
}
fd2=open(“raushan2″,O_RDONLY);
if(fd2<0)
{
perror(“\n open is failure”);
goto OUT;
}
len=sizeof(struct data);
count=read(fd2,&data1,len);
printf(“\n bytes is %d %d %d %c”,count,data1.a,data1.b,data1.opr);
ret=access(“raushan3″,F_OK);
if(ret==-1)
{
ret=mkfifo(“raushan3″,777);
}
fd3=open(“raushan3″,O_WRONLY);
if(fd3<0)
{
perror(“\n open is failure”);
goto OUT;
}
len1=sizeof(struct data);
count=write(fd3,&data1,len1);
printf(“\n bytes is %d”,count);
fd3=open(“raushan3″,O_RDONLY);
len=sizeof(result);
count=read(fd3,&result,len);
printf(“\n result=%d”,result);
close(fd3);
fd2=open(“raushan2″,O_WRONLY);
len=sizeof(result);
count=write(fd2,&result,len);
printf(“written result is %d\n”,result);
return 0;
OUT:
return-1;
}
@
1.1
log
@Initial revision
@
text
@d6 1
a6 1
int len,len1,ret,count,fd,fd1,result;
d24 2
a25 1
ret=mkfifo(“raushan1″,777);
d40 1
d46 20
d67 19
@
description:
this progra is three client and three processing with pipe using
—————————-
revision 1.1
date: 2014/05/17 07:12:46; author: root; state: Exp;
Initial revision
=============================================================================
1.mknod
Syntax
int mknod(const char *pathname, mode_t mode, dev_t dev);
where pathname corresponds to the fifo name, mode corresponds to the
file permissions. Since mknod can be used to create a regular file,
block or charcter special files and fifo. We have to specify the file
type. Corresponding to FIFO: the file type is S_IFIFO.
2. mkfifo
Syntax
int mkfifo(const char *pathname, mode_t mode);
where pathname correspnds to fifo name and mode corresponds to file
mode.
description——
The mknod subroutine creates a new regular file, special file, or FIFO file. Using the mk
nod subroutine to create file types (other than FIFO or special files) requires root user authority.
For the mknod subroutine to complete successfully, a process must have both search and write permission in the parent directory of the Path parameter.
The mkfifo subroutine is an interface to the mknod subroutine, where the new file to be created is a FIFO or special file. No special system privileges are required.
The new file has the following characteristics:
File type is specified by the Mode parameter.
Owner ID is set to the effective user ID of the process.
Group ID of the file is set to the group ID of the parent directory if the SetGroupID attribute (S_ISGID) of the parent directory is set. Otherwise, the group ID of the file is set to the effective group ID of the calling process.
Permission and attribute bits are set according to the value of the Mode parameter. All bits set in the file-mode creation mask of the process are cleared.
Upon successful completion, the mkfifo subroutine marks for update the st_atime, st_ctime, and st_mtime fields of the file. It also marks for update the st_ctime and st_mtime fields of the directory that contains the new entry.
If the new file is a character special file having the S_IMPX attribute (multiplexed character special file), when the file is used, additional path-name components can appear after the path name as if it were a directory. The additional part of the path name is available to the device driver of the file for interpretation. This feature provides a multiplexed interface to the device driver.
Signals are one of the oldest inter-process communication methods used by Unix TM systems. They are used to signal asynchronous events to one or more processes. A signal could be generated by a keyboard interrupt or an error condition such as the process attempting to access a non-existent location in its virtual memory. Signals are also used by the shells to signal job control commands to their child processes.
There are a set of defined signals that the kernel can generate or that can be generated by other processes in the system, provided that they have the correct privileges. You can list a system’s set of signals using the kill command (kill -l), on my Intel Linux box this gives:
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
5) SIGTRAP 6) SIGIOT 7) SIGBUS 8) SIGFPE
9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2
13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD
18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN
22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO
30) SIGPWR
The numbers are different for an Alpha AXP Linux box. Processes can choose to ignore most of the signals that are generated, with two notable exceptions: neither the SIGSTOP signal which causes a process to halt its execution nor the SIGKILL signal which causes a process to exit can be ignored. Otherwise though, a process can choose just how it wants to handle the various signals. Processes can block the signals and, if they do not block them, they can either choose to handle them themselves or allow the kernel to handle them. If the kernel handles the signals, it will do the default actions required for this signal. For example, the default action when a process receives the SIGFPE (floating point exception) signal is to core dump and then exit. Signals have no inherent relative priorities. If two signals are generated for a process at the same time then they may be presented to the process or handled in any order. Also there is no mechanism for handling multiple signals of the same kind. There is no way that a process can tell if it received 1 or 42 SIGCONT signals.
Linux implements signals using information stored in the task_struct for the process. The number of supported signals is limited to the word size of the processor. Processes with a word size of 32 bits can have 32 signals whereas 64 bit processors like the Alpha AXP may have up to 64 signals. The currently pending signals are kept in the signal field with a mask of blocked signals held in blocked. With the exception of SIGSTOP and SIGKILL, all signals can be blocked. If a blocked signal is generated, it remains pending until it is unblocked. Linux also holds information about how each process handles every possible signal and this is held in an array of sigaction data structures pointed at by the task_struct for each process. Amongst other things it contains either the address of a routine that will handle the signal or a flag which tells Linux that the process either wishes to ignore this signal or let the kernel handle the signal for it. The process modifies the default signal handling by making system calls and these calls alter the sigaction for the appropriate signal as well as the blocked mask.
Not every process in the system can send signals to every other process, the kernel can and super users can. Normal processes can only send signals to processes with the same uid and gid or to processes in the same process group1. Signals are generated by setting the appropriate bit in the task_struct’s signal field. If the process has not blocked the signal and is waiting but interruptible (in state Interruptible) then it is woken up by changing its state to Running and making sure that it is in the run queue. That way the scheduler will consider it a candidate for running when the system next schedules. If the default handling is needed, then Linux can optimize the handling of the signal. For example if the signal SIGWINCH (the X window changed focus) and the default handler is being used then there is nothing to be done.
Signals are not presented to the process immediately they are generated., they must wait until the process is running again. Every time a process exits from a system call its signal and blocked fields are checked and, if there are any unblocked signals, they can now be delivered. This might seem a very unreliable method but every process in the system is making system calls, for example to write a character to the terminal, all of the time. Processes can elect to wait for signals if they wish, they are suspended in state Interruptible until a signal is presented. The Linux signal processing code looks at the sigaction structure for each of the current unblocked signals.
If a signal’s handler is set to the default action then the kernel will handle it. The SIGSTOP signal’s default handler will change the current process’s state to Stopped and then run the scheduler to select a new process to run. The default action for the SIGFPE signal will core dump the process and then cause it to exit. Alternatively, the process may have specfied its own signal handler. This is a routine which will be called whenever the signal is generated and the sigaction structure holds the address of this routine. The kernel must call the process’s signal handling routine and how this happens is processor specific but all CPUs must cope with the fact that the current process is running in kernel mode and is just about to return to the process that called the kernel or system routine in user mode. The problem is solved by manipulating the stack and registers of the process. The process’s program counter is set to the address of its signal handling routine and the parameters to the routine are added to the call frame or passed in registers. When the process resumes operation it appears as if the signal handling routine were called normally.
Linux is POSIX compatible and so the process can specify which signals are blocked when a particular signal handling routine is called. This means changing the blocked mask during the call to the processes signal handler. The blocked mask must be returned to its original value when the signal handling routine has finished. Therefore Linux adds a call to a tidy up routine which will restore the original blocked mask onto the call stack of the signalled process. Linux also optimizes the case where several signal handling routines need to be called by stacking them so that each time one handling routine exits, the next one is called until the tidy up routine is called.
IPC:Semaphores
Semaphores are a programming construct designed by E. W. Dijkstra in the late 1960s. Dijkstra’s model was the operation of railroads: consider a stretch of railroad in which there is a single track over which only one train at a time is allowed. Guarding this track is a semaphore. A train must wait before entering the single track until the semaphore is in a state that permits travel. When the train enters the track, the semaphore changes state to prevent other trains from entering the track. A train that is leaving this section of track must again change the state of the semaphore to allow another train to enter. In the computer version, a semaphore appears to be a simple integer. A process (or a thread) waits for permission to proceed by waiting for the integer to become 0. The signal if it proceeds signals that this by performing incrementing the integer by 1. When it is finished, the process changes the semaphore’s value by subtracting one from it.
Semaphores let processes query or alter status information. They are often used to monitor and control the availability of system resources such as shared memory segments.
Semaphores can be operated on as individual units or as elements in a set. Because System V IPC semaphores can be in a large array, they are extremely heavy weight. Much lighter weight semaphores are available in the threads library and POSIX semaphores (see below briefly). Threads library semaphores must be used with mapped memory . A semaphore set consists of a control structure and an array of individual semaphores. A set of semaphores can contain up to 25 elements.
In a similar fashion to message queues, the semaphore set must be initialized using semget(); the semaphore creator can change its ownership or permissions using semctl(); and semaphore operations are performed via the semop() function.
Controlling Semaphores
semctl() changes permissions and other characteristics of a semaphore set. It is prototyped as follows:
int semctl(int semid, int semnum, int cmd, union semun arg);
It must be called with a valid semaphore ID, semid. The semnum value selects a semaphore within an array by its index. The cmd argument is one of the following control flags:
GETVAL
— Return the value of a single semaphore.
SETVAL
— Set the value of a single semaphore. In this case, arg is taken as arg.val, an int.
GETPID
— Return the PID of the process that performed the last operation on the semaphore or array.
GETNCNT
— Return the number of processes waiting for the value of a semaphore to increase.
GETZCNT
— Return the number of processes waiting for the value of a particular semaphore to reach zero.
GETALL
— Return the values for all semaphores in a set. In this case, arg is taken as arg.array, a pointer to an array of unsigned shorts (see below).
SETALL
— Set values for all semaphores in a set. In this case, arg is taken as arg.array, a pointer to an array of unsigned shorts.
IPC_STAT
— Return the status information from the control structure for the semaphore set and place it in the data structure pointed to by arg.buf, a pointer to a buffer of type semid_ds.
IPC_SET
— Set the effective user and group identification and permissions. In this case, arg is taken as arg.buf.
IPC_RMID
— Remove the specified semaphore set.
when the fork system call is invoked the fork is mappped with the clone system call .
the kernel stores the list of processes in circular doubly link list called task list
each element in the task_list is a process descriptor of type struct task_struct which is defined in
->task_struct contain all the information related to the process
->the process descriptor contain the data that described the execution program-openfile,the process address space ,pending signals ,p
->the task_struct contain the parent pid task_struct.
struct task_struct
{
process descriptor
unsigned long state;
int prio;
unsigned long policy;
struct task_struct *parent; //struct task_struct of the parent
struct list_head tasks;
pid_t pid;
} process_descriptor;
the linklist produced by this task_struct consicute the Kernel process table whos first process after booting process is the init pro
kthreadadd function to make more system related processes needed for the operation of the system OS.
struct task_struct was stored at the end of the kernel stack of each process
Linux implements fork() via the clone() system call.This call takes a series of flags that
specify which resources, if any, the parent and child process should share.The
fork(), vfork(), and __clone() library calls all invoke the clone() system call with the
requisite flags.The clone() system call, in turn, calls do_fork().
The bulk of the work in forking is handled by do_fork(), which is defined in
kernel/fork.c.This function calls copy_process() and then starts the process running.
The interesting work is done by copy_process():
1. It calls dup_task_struct(), which creates a new kernel stack, thread_info struc-
ture, and task_struct for the new process.The new values are identical to those of
the current task.At this point, the child and parent process descriptors are identical.
2. It then checks that the new child will not exceed the resource limits on the num-
ber of processes for the current user.
3. The child needs to differentiate itself from its parent.Various members of the
process descriptor are cleared or set to initial values. Members of the process
descriptor not inherited are primarily statistically information.The bulk of the val-
ues in task_struct remain unchanged.
4. The child’s state is set to TASK_UNINTERRUPTIBLE to ensure that it does not yet run.
5.copy_process() calls copy_flags() to update the flags member of the
task_struct.
6. It calls alloc_pid() to assign an available PID to the new task.
7. Depending on the flags passed to clone(), copy_process() either duplicates or
shares open files, filesystem information, signal handlers, process address space, and
namespace.These resources are typically shared between threads in a given process;
otherwise they are unique and thus copied here.
8. Finally, copy_process() cleans up and returns to the caller a pointer to the new
child.
Back in do_fork(), if copy_process() returns successfully, the new child is woken up
and run. Deliberately, the kernel runs the child process first. In the common case of the
child simply calling exec() immediately, this eliminates any copy-on-write overhead that
would occur if the parent ran first and began writing to the address space.
RCS file: write.c,v
Working file: write.c
head: 1.81
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 81; selected revisions: 81
description:
this is the file for user write like operation
—————————-
revision 1.81
date: 2014/05/16 12:53:09; author: root; state: Exp; lines: +1 -1
successful working for multiple quantum,multiple QSETS and scullqsets
—————————-
revision 1.80
date: 2014/05/16 08:37:31; author: root; state: Exp; lines: +2 -2
*** empty log message ***
—————————-
revision 1.79
date: 2014/05/16 08:35:54; author: root; state: Exp; lines: +2 -2
testing
—————————-
revision 1.74
date: 2014/05/16 08:19:49; author: root; state: Exp; lines: +2 -2
testing
—————————-
revision 1.73
date: 2014/05/16 08:11:42; author: root; state: Exp; lines: +4 -0
error resolved as no. of quantum are multiple of 8 so it will not come out of the loop
untill 8 quantum complete evn if the noctw next
—————————-
revision 1.60
date: 2014/05/16 05:45:12; author: root; state: Exp; lines: +14 -15
2 scullqset
—————————-
revision 1.59
date: 2014/05/15 18:17:54; author: root; state: Exp; lines: +1 -1
*** empty log message ***
—————————-
revision 1.58
date: 2014/05/15 18:16:35; author: root; state: Exp; lines: +13 -8
multiple scullqset and 2 scullqset
—————————-
revision 1.57
date: 2014/05/15 17:43:02; author: root; state: Exp; lines: +1 -1
print ret value
—————————-
revision 1.56
date: 2014/05/15 10:33:38; author: root; state: Exp; lines: +1 -1
return nocsw from the write function
—————————-
revision 1.55
date: 2014/05/15 10:30:42; author: root; state: Exp; lines: +3 -0
printk the nocsw and noctw
—————————-
revision 1.48
date: 2014/05/15 09:35:00; author: root; state: Exp; lines: +29 -20
enterring no. of quantum in respective qsets
—————————-
revision 1.47
date: 2014/05/13 18:08:24; author: root; state: Exp; lines: +8 -8
*** empty log message ***
—————————-
revision 1.46
date: 2014/05/13 17:33:27; author: root; state: Exp; lines: +1 -1
testing
—————————-
revision 1.45
date: 2014/05/13 17:31:42; author: root; state: Exp; lines: +6 -4
calculation on copy on user
—————————-
revision 1.44
date: 2014/05/13 16:54:48; author: root; state: Exp; lines: +13 -13
corrected copyfromuser
—————————-
revision 1.43
date: 2014/05/13 15:38:39; author: root; state: Exp; lines: +4 -3
*** empty log message ***
—————————-
revision 1.42
date: 2014/05/13 14:43:34; author: root; state: Exp; lines: +2 -2
testing
—————————-
revision 1.41
date: 2014/05/13 14:38:24; author: root; state: Exp; lines: +3 -1
included memset in both the kmalloc used in function
————————–
—————————-
revision 1.29
date: 2014/05/13 09:06:22; author: root; state: Exp; lines: +3 -3
lsize typecast to size
—————————-
revision 1.28
date: 2014/05/13 09:04:28; author: root; state: Exp; lines: +2 -2
type cast the size from the write function
—————————-
revision 1.27
date: 2014/05/13 08:46:18; author: root; state: Exp; lines: +5 -1
use of copy_from
user….copy_from_user(to,from,sizeofbuffer) :
to=lsculldev->data
from =buffer
—————————-
revision 1.26
date: 2014/05/12 10:34:04; author: root; state: Exp; lines: +1 -1
*** empty log message ***
—————————-
revision 1.25
date: 2014/05/12 10:33:06; author: root; state: Exp; lines: +3 -2
included void *p
—————————-
revision 1.24
date: 2014/05/12 10:25:26; author: root; state: Exp; lines: +4 -4
added allocate_quantum
—————————-
revision 1.23
date: 2014/05/12 10:04:53; author: root; state: Exp; lines: +2 -2
*** empty log message ***
—————————-
revision 1.22
date: 2014/05/12 09:56:55; author: root; state: Exp; lines: +7 -7
write allocate_scullqset
—————————-
revision 1.21
revision 1.18
date: 2014/05/12 08:48:04; author: root; state: Exp; lines: +2 -2
remove OUT :
—————————-
revision 1.17
date: 2014/05/12 08:46:33; author: root; state: Exp; lines: +6 -6
chages in create_skull change lsculldev to lscullqset
—————————-
revision 1.16
date: 2014/05/12 08:41:50; author: root; state: Exp; lines: +1 -0
prototype of crete_skull not there
—————————-
revision 1.15
date: 2014/05/12 08:36:44; author: root; state: Exp; lines: +160 -1
in this file i have wrote the scull
first calculate noqset and makwe the required no. of qset and then the quantum in those queset
use 30 bytes of data as a reference to send it to the DD
—————————-
#register using the alloc_chrdev_region and unregister using the unregister_chrdev_region and then define the struct Sculldev and allocate the memory for it and then pointing the address of kmalloc with this struct type pointer.. RCS file: cleanup.c,v Working file: cleanup.c head: 1.6 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 6; selected revisions: 6 description: use the module_exit(exitfn) and define the declaration of exitfn ---------------------------- revision 1.6 date: 2014/05/06 03:28:56; author: root; state: Exp; lines: +1 -0 kfree the memory allocated during kmalloc. ---------------------------- revision 1.5 date: 2014/05/06 02:35:09; author: root; state: Exp; lines: +2 -1 include the declaration.h in this. ---------------------------- revision 1.4 date: 2014/05/06 02:32:49; author: root; state: Exp; lines: +1 -1 *** empty log message *** ---------------------------- revision 1.3 date: 2014/05/06 02:30:41; author: root; state: Exp; lines: +1 -1 the function name we use as __ ---------------------------- revision 1.2 date: 2014/05/06 02:06:30; author: root; state: Exp; lines: +3 -1 call unregister_chrdev_region for the unregistration. ---------------------------- revision 1.1 date: 2014/05/06 01:00:24; author: root; state: Exp; Initial revision ============================================================================= RCS file: declaration.h,v Working file: declaration.h head: 1.3 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 3; selected revisions: 3 description: declare the extern variable as dev, nod, minorno and majorno. ---------------------------- revision 1.3 date: 2014/05/06 06:25:08; author: root; state: Exp; lines: +2 -2 *** empty log message *** ---------------------------- revision 1.2 date: 2014/05/06 03:29:21; author: root; state: Exp; lines: +6 -0 declare a structure SkullDev with a structure cdev define in cdev,h ---------------------------- revision 1.1 date: 2014/05/06 02:07:46; author: root; state: Exp; Initial revision ============================================================================= RCS file: header.h,v Working file: header.h head: 1.9 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 9; selected revisions: 9 description: including the linux/modules. includding the linux/init. define GPL. ---------------------------- revision 1.9 date: 2014/05/06 06:36:59; author: root; state: Exp; lines: +1 -1 *** empty log message *** ---------------------------- revision 1.8 date: 2014/05/06 06:33:38; author: root; state: Exp; lines: +1 -1 *** empty log message *** ---------------------------- revision 1.7 date: 2014/05/06 06:31:04; author: root; state: Exp; lines: +2 -0 include slab.h for the kmalloc and kdev_t for the Macros MINOR and MAJOR. ---------------------------- revision 1.6 date: 2014/05/06 06:26:43; author: root; state: Exp; lines: +1 -0 include cdev.h header file for struct cdev ---------------------------- revision 1.5 date: 2014/05/06 06:24:27; author: root; state: Exp; lines: +4 -0 declare the struct SkullDev in header instead of in declaration.h. ---------------------------- revision 1.4 date: 2014/05/06 02:12:04; author: root; state: Exp; lines: +4 -4 redfine the macro in header file again. ---------------------------- revision 1.3 date: 2014/05/06 02:03:21; author: root; state: Exp; lines: +17 -0 include the linux/fs.h difine the macros DEVNAME N ---------------------------- revision 1.2 date: 2014/05/06 01:04:44; author: root; state: Exp; lines: +1 -1 correct the license GPL ---------------------------- revision 1.1 date: 2014/05/06 00:58:23; author: root; state: Exp; Initial revision ============================================================================= RCS file: init.c,v Working file: init.c head: 1.12 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 12; selected revisions: 12 description: use the module_init(initfn) and define the declaration of initfn ---------------------------- revision 1.12 date: 2014/05/06 06:44:23; author: root; state: Exp; lines: +2 -1 initilize the struct ScullDev above the function name ---------------------------- revision 1.11 date: 2014/05/06 06:24:59; author: root; state: Exp; lines: +5 -5 *** empty log message *** ---------------------------- revision 1.10 date: 2014/05/06 03:34:40; author: root; state: Exp; lines: +5 -5 *** empty log message *** ---------------------------- revision 1.9 date: 2014/05/06 03:31:46; author: root; state: Exp; lines: +1 -1 *** empty log message *** ---------------------------- revision 1.8 date: 2014/05/06 03:26:36; author: root; state: Exp; lines: +9 -0 call kmalloc and allocate the space uptp the structure SkullDev. SkullDev is used to map the memory of the Device Driver. defint the *skulldev which is extern and define in the struct SkullDev ---------------------------- revision 1.7 date: 2014/05/06 02:55:59; author: root; state: Exp; lines: +1 -1 *** empty log message *** ---------------------------- revision 1.6 date: 2014/05/06 02:31:58; author: root; state: Exp; lines: +1 -1 *** empty log message *** ---------------------------- revision 1.5 date: 2014/05/06 02:30:20; author: root; state: Exp; lines: +2 -2 the fuction name we use __ ---------------------------- revision 1.4 date: 2014/05/06 02:24:27; author: root; state: Exp; lines: +2 -2 *** empty log message *** ---------------------------- revision 1.3 date: 2014/05/06 02:17:40; author: root; state: Exp; lines: +5 -2 initialize the extern variable to MACRO within the function itself ---------------------------- revision 1.2 date: 2014/05/06 02:05:12; author: root; state: Exp; lines: +21 -1 call alloc chr_dev region to register the DD into kernel and then call MAJOR and MINOR to display ita majorno and mno. ---------------------------- revision 1.1 date: 2014/05/06 00:59:15; author: root; state: Exp; Initial revision =============================================================================
ead 1.1;
access;
symbols;
locks
root:1.1; strict;
comment @ * @;
1.1
date 2014.05.14.23.41.10; author root; state Exp;
branches;
next ;
desc
@semaphore with semget,semctl,semop.
@
1.1
log
@Initial revision
@
text
@#include<stdio.h>
#include<linux/sem.h>
#include<stdlib.h>
int main()
{
int i,aa,aaa;
union semun u;
u.val=1;
struct sembuf sem1;
sem1.sem_num=0;
sem1.sem_op=-1;
sem1.sem_flg=SEM_UNDO;
aa=semget((key_t)1234,1,IPC_CREAT|0777);
if(aa<0)
{
perror(“semget failure\n”);
goto OUT;
}
aaa=semctl(aa,0,SETVAL,0);
if(aaa<0)
{
perror(“segctl failure\n”);
goto OUT;
}
semop(aa,&sem1,0);
for(i=1;i<=3;i++)
{
printf(“hello i m into critical section =%d\n”,getpid());
sleep(2);
printf(” i m into critical section =%d\n”,getpid());
sleep(2);
printf(“bye i m into critical section =%d\n”,getpid());
}
sem1.sem_num=0;
sem1.sem_op=1;
sem1.sem_flg=SEM_UNDO;
semop(aa,&sem1,0);
return 0;
OUT:
return -1;
}
@
RCS file: user1.c,v
Working file: user1.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
this is mainly a chat box btween two users ,a full duplexer one
each user can simultaneously recieve or can send the msg
for this to be happened we used mesaagequeue which helps in holding the messages .
nd its dual processor that mean user one can both recieve or can send the msg to another user at a same time
this to be happened we need multithread concept
moving back to this project use 1 can both recieve or can send msgs at a same time .
as soon user 1 typed “end” then it will ask user 2 to type same end string after that session gets terminated.
—————————-
revision 1.1 locked by: root;
date: 2014/05/14 08:32:37; author: root; state: Exp;
Initial revision
=============================================================================
Semaphores are a programming construct designed by E. W. Dijkstra in the late 1960s. Dijkstra’s model was the operation of railroads: consider a stretch of railroad in which there is a single track over which only one train at a time is allowed. Guarding this track is a semaphore. A train must wait before entering the single track until the semaphore is in a state that permits travel. When the train enters the track, the semaphore changes state to prevent other trains from entering the track. A train that is leaving this section of track must again change the state of the semaphore to allow another train to enter. In the computer version, a semaphore appears to be a simple integer. A process (or a thread) waits for permission to proceed by waiting for the integer to become 0. The signal if it proceeds signals that this by performing incrementing the integer by 1. When it is finished, the process changes the semaphore’s value by subtracting one from it.
The function semget() initializes or gains access to a semaphore. It is prototyped by:
int semget(key_t key, int nsems, int semflg);
When the call succeeds, it returns the semaphore ID (semid).
The key argument is a access value associated with the semaphore ID.
The nsems argument specifies the number of elements in a semaphore array. The call fails when nsems is greater than the number of elements in an existing array; when the correct count is not known, supplying 0 for this argument ensures that it will succeed.
The semflg argument specifies the initial access permissions and creation control flags.
The sigaction system call is used to change the action taken by process on
receipt of a specific signal….It is used in program as:
sigaction(int,struct sigaction *new,struct sigaction *old);
Various macros used for sigaction are:
sigismember
sigaddset
sigdelset
sigemptyset
sigfillset
sigorset
sigandset
sigproemask
What are processes and threads??
In computing, a device driver (commonly referred to as simply a driver) is a computer program that operates or controls a particular type of device that is attached to a computer.[1] A driver provides a software interface to hardware devices, enabling operating systems and other computer programs to access hardware functions without needing to know precise details of the hardware being used.
A driver typically communicates with the device through the computer bus or communications subsystem to which the hardware connects. When a calling program invokes a routine in the driver, the driver issues commands to the device. Once the device sends data back to the driver, the driver may invoke routines in the original calling program. Drivers are hardware-dependent and operating-system-specific. They usually provide the interrupt handling required for any necessary asynchronous time-dependent hardware interface.
| Operating systems |
|---|
|
 |
| Common features |
