EmbLogic's Blog

Kernel Space and User Space

Understanding of Kernel space and User space in detail is very important if you wish to have a strong base of Linux Kernel.

  • Here Kernel Space and User Space corresponds to their Virtual address space.
  • Every process in linux utilizes  its own separate virtual space.
  • In a linux system based on 32 bit Architecture, user space address space corresponds to lower 3GB of virtual space and kernel space the upper 1GB.(general way)
  • The kernel space virtual address space is shared between all the processes.
  • When a process is active, it can either be running in “user mode” or “kernel mode”.
  • In a process is running in User mode it means that the CPU is running the user space side of code.
  • A process running in the user mode has limited capability and is controlled by a flag in the CPU.
  • Even though the kernel memory is present in the process’s memory map the user space code is not allowed to access the kernel space code.(can do in some special way).
  • When a process wants to do something other than move data around in its own (userspace) virtual memory, like opening a file for example, it must make a syscall to communicate with the kernel space.
  • Each CPU architecture has it’s unique way of making a system call but the basic remains the same i.e.
  • A magic instruction is executed, the CPU turns on the “privileged mode” flag, and jumps to a special address in kernel space, the “syscall entry point”.( read another post to understand what syscall is)
  • Now when the syscall has reached the kernel space then the process is running in kernel mode and executing instructions from the kernel space memory.
  • Taking the same example of open system call, to find the requested file, the kernel may consult with filesystem drivers (to figure out where the file is) and block device drivers (to load the necessary blocks from disk) or network device drivers and protocols (to load the file from a remote source).
  • These drivers can be either built in or can be loaded as module but the key point that remains it that they are the part of kernel space.
  • Loading a module is done with a syscall that asks the kernel to copy the module’s code and data into kernel space and run its initialization code in kernel mode.
  • If the kernel can’t process the request then the process is made to sleep by the kernel and when the request is complete then the syscall returns back to the user space.
  • Returning back to user mode means restoring the CPU registers to what they were before coming to Kernel Mode and changing the CPU privilege level to non-privilege .
  • Apart from syscalls there are some other things that take CPU to kernel mode eg. 
 

1. Page faults- If the process tries to access a virtual memory address that doesn’t have a physical address assigned to it then the CPU enters the Kernel mode  and jumps to page fault handler and the kernel sees whether the virtual addresss is valid or not and depending upon this it either tries to create a physical page for the given virtual address or if it can’t then sends a segmentation fault signal (SIGSEGV).

 
2. Interrupts- When the CPU receives some interrupt from the hardware then it jumps to the kernel mode and executes the interrupt handler and when the kernel is finished handing the interrupt the the code return to the user space where it was executing.


Posted in Linux Internals and System Programming | Leave a comment

DEVICE DRIVER

Character Device Driver: In order to create a link between your device means your hardware either it is internal or externally attached and user application we need a set of rules which will define how your concerned device shall deal with application make sure user will get a satisfactory output as desired.

First let me give you a brief idea of architecture which helped me to create my device driver. Its is mainly divided in two basic parts first one is know as your USER LEVEL where application runs and the 2nd is your KERNEL LEVEL where your device driver is defined.

This is how a link is created between application and device through device driver.

APPLICATION——->NODE——>DEVICE DRIVER——–> DEVICE

NODE is an interface between USER LEVEL and KERNEL LEVEL..

There are few kernel defined structure and rest are user defined structure through which we can define the functionality of our device driver.

KERNEL DEFINED STRUCTURE– 1->Struct File 2->struct Inode 3->Cdev. etc

USER DEFINED STRUCTURE– 1->struct ScullDev 2-> struct Scullqset 3->struct file operations.

Lets look how all these all structure works one by one.

Scull is a memory space which is allocated in machine memory to your device. in scull we have two vital structure know as struct Sculldev and struct Scullqset. The former one is the starting point of scull as well as contains data about all the scullqset present in your scull in a way it contains metadata. its member are as fallow- 1-*scullqset 2-no of scullqset 3-datasize 4-quantum size 5-device size. and last but not the least  struct Cdev.

The later one Scullqset is a structure which store data or information. it mainly has two member first one is a pointer to next scullqset and the second one double pointer to y.our data, means first it will point to an array of pointer known as qset ,contains the add of quantum where actually our data is kept.

Struct file operations-> it generally defines the behavior of our device. it is used here to map the user level system calls to programmer defined system calls. some system calls are OPEN,CLOSE,WRITE,READ… etc

Struct Cdev—> it mainly has three member 1st one is owner which specifies about its owner name 2nd is a pointer to file operation,3rd to dev which contains major and minor no. now what is this major and minor no. lets have a look before we proceed further

Major no is a number which is given to each and every device driver we have in our machine and minor no is the number which represents your the device associated with that particular device driver. struct Cdev is your device representation in kernel Space.

Now comes kernel level structures into picture. STRUCT INODE .. as we all know that in linux everything is file either it is a text file, some kind of code or any device with each and every file there is an associated inode structure , here we will mainly concentrate and concerned about which is particularly represents our device. “inode is the only way through which we can or its better to say our application can interact with our device. main member are i_cev which points to your struct cdev. pointer to file operations.

Struct file-> members are *f_pos which takes the account of the cursor in your file. pointer to file operations , *private data which will help us to do mapping from your user level to kernal level as its stores the address of your SCULL so we can access all the data which we have stored in quantum part of scullqset from user level. this is all about the architecture now lets have  look on the operations or working.

STEPS TO BE FOLLOWED:

1. Insmod which will load our module, module is a source code which is loaded on demand.

2. Registration:register our device driver and device so that DD will get a major number and device gets its own minor number.

3.Allocation: Allocate space to Scull in machine memory.

4.Initialize Scull–> cdev_init— create link between struct inode and struct cdev… define owner.. cdev_add make attribute of device available to our kernael.

5. Sculldev initiallization: define size of qset,quantun,device..etc

6. Scull Trim. flash data if present in the memory space which is assigned to scull

7.Open: define open system call.

8. Write: before doing that allocate space to Scullqset then to qset and at last to quantum now we can write data to our quantum, LSEEK if needed.

9. Read: read whatever you have written to quantum.

10. Release: de-allocate all the space, unregister your device and DD, remove your module

Character Device Driver: In order to create a link between your device means your hardware either it is internal or externally attached and user application we need a set of rules which will define how your concerned device shall deal with application make sure user will get a satisfactory output as desired.

First let me give you a brief idea of architecture which helped me to create my device driver. Its is mainly divided in two basic parts first one is know as your USER LEVEL where application runs and the 2nd is your KERNEL LEVEL where your device driver is defined.

This is how a link is created between application and device through device driver.

APPLICATION——->NODE——>DEVICE DRIVER——–> DEVICE

NODE is an interface between USER LEVEL and KERNEL LEVEL..

There are few kernel defined structure and rest are user defined structure through which we can define the functionality of our device driver.

KERNEL DEFINED STRUCTURE– 1->Struct File 2->struct Inode 3->Cdev. etc

USER DEFINED STRUCTURE– 1->struct ScullDev 2-> struct Scullqset 3->struct file operations.

Lets look how all these all structure works one by one.

Scull is a memory space which is allocated in machine memory to your device. in scull we have two vital structure know as struct Sculldev and struct Scullqset. The former one is the starting point of scull as well as contains data about all the scullqset present in your scull in a way it contains metadata. its member are as fallow- 1-*scullqset 2-no of scullqset 3-datasize 4-quantum size 5-device size. and last but not the least  struct Cdev.

The later one Scullqset is a structure which store data or information. it mainly has two member first one is a pointer to next scullqset and the second one double pointer to y.our data, means first it will point to an array of pointer known as qset ,contains the add of quantum where actually our data is kept.

Struct file operations-> it generally defines the behavior of our device. it is used here to map the user level system calls to programmer defined system calls. some system calls are OPEN,CLOSE,WRITE,READ… etc

Struct Cdev—> it mainly has three member 1st one is owner which specifies about its owner name 2nd is a pointer to file operation,3rd to dev which contains major and minor no. now what is this major and minor no. lets have a look before we proceed further

Major no is a number which is given to each and every device driver we have in our machine and minor no is the number which represents your the device associated with that particular device driver. struct Cdev is your device representation in kernel Space.

Now comes kernel level structures into picture. STRUCT INODE .. as we all know that in linux everything is file either it is a text file, some kind of code or any device with each and every file there is an associated inode structure , here we will mainly concentrate and concerned about which is particularly represents our device. “inode is the only way through which we can or its better to say our application can interact with our device. main member are i_cev which points to your struct cdev. pointer to file operations.

Struct file-> members are *f_pos which takes the account of the cursor in your file. pointer to file operations , *private data which will help us to do mapping from your user level to kernal level as its stores the address of your SCULL so we can access all the data which we have stored in quantum part of scullqset from user level. this is all about the architecture now lets have  look on the operations or working.

STEPS TO BE FOLLOWED:

1. Insmod which will load our module, module is a source code which is loaded on demand.

2. Registration:register our device driver and device so that DD will get a major number and device gets its own minor number.

3.Allocation: Allocate space to Scull in machine memory.

4.Initialize Scull–> cdev_init— create link between struct inode and struct cdev… define owner.. cdev_add make attribute of device available to our kernael.

5. Sculldev initiallization: define size of qset,quantun,device..etc

6. Scull Trim. flash data if present in the memory space which is assigned to scull

7.Open: define open system call.

8. Write: before doing that allocate space to Scullqset then to qset and at last to quantum now we can write data to our quantum, LSEEK if needed.

9. Read: read whatever you have written to quantum.

10. Release: de-allocate all the space, unregister your device and DD, remove your module

Posted in Uncategorized | Leave a comment

ipc using pipes( with two requesting and processing client)

RCS file: req.c,v
Working file: req.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
this is the requesting program in which i am adding two value.
the value sent by the request is read by the server.
—————————-
revision 1.1
date: 2014/05/13 06:50:30; author: priya; state: Exp;
Initial revision

RCS file: req1.c,v
Working file: req1.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
this is the requesting program in which i am subtracting two values.
the value given by requesting is read by server.
—————————-
revision 1.1
date: 2014/05/13 06:52:47; author: priya; state: Exp;
Initial revision

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 program for server which accepts all the request sent by requesting client and forward the request to the processing client.
in this i have created two pipes for receiving and sending request respectively .
—————————-
revision 1.1
date: 2014/05/13 06:54:25; author: priya; state: Exp;
Initial revision
=============================================================================

RCS file: proc.c,v
Working file: proc.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
this is the program for processing client in which i have added two values.
—————————-
revision 1.1
date: 2014/05/13 06:58:28; author: priya; state: Exp;
Initial revision
=============================================================================

RCS file: proc1.c,v
Working file: proc1.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
this is the program for processing client in which i have subtracted two values.
in this processing of request sent by server is done.
—————————-
revision 1.1
date: 2014/05/13 07:00:10; author: priya; state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

program to convert decimal to binary & octa & hexa

“1.Binary”;
2.Ocatal;
3.hexadecimal;

switch(choice)
{
case 1:
base=2;
case 2:
base=8;
case 3:
base=16;
“enter your no\n”;
convert(num,base);

convert(int num,int base)
{

int rem;
rem=num%base;
num/=base;
if(num>0)
convert(num,base);
if(rem<10)
printf(“%d”,rem);
else
printf(“%c”,rem-10 + ‘A’);

}

Posted in Data Structures with C | Leave a comment

project05==character driver

Common Errors which most of us will face while doing character drivers

1) Multiple definitions of the variable {bcoz of wrong use of extern}

2)control reaches end of non-void function{bcoz not returning any value to that non-void function}

3)warning: variable ‘lscullqset’ set but not used {bcoz variables initilised but not used}
4)***-1 Unknown symbol in module {bcoz u have used a variable which was not able to reference the driver properly}
5)warning: assignment from incompatible pointer type [enabled by default]
/home/project_05/devwrite.c:6:20: warning: variable ‘lscullqset’ set but not used [-Wunused-but-set-variable]
/home/project_05/devwrite.c:4:49: warning: unused variable ‘device_size’ [-Wunused-variable]
/home/project_05/devwrite.c:4:35: warning: unused variable ‘data_size’ [-Wunused-variable]
/home/project_05/devwrite.c:4:22: warning: unused variable ‘qset_size’ [-Wunused-variable]
/home/project_05/devwrite.c:4:7: warning: unused variable ‘quantum_size’ [-Wunuse

Posted in Character Driver | Leave a comment

project 05==character driver

things to be kept in mind while doing “Character Driver”

1>Be very patient as you will get different errors with silly solutions.

2>As you are dealing with multiple files like in my case files are header.h,declaration.h,init.c,clean.c,fops.h,prototypes.h,devopen.c,

devrelease.c,devwrite.c…BE CAREFUL about the handling the variables used in these files….

3> Using EXTERN command ,,, just keep a single logic where to declare extern and how to use it.

4>sometimes the TEST script can make a issue…so also update your script acc. to programs.

5>Don’t used any variable or pointer which has no use.although there would be warning no error…but it will create problems in inserting the driver.

 

 

 

Posted in Character Driver | Leave a comment

CHARACTER DRIVER

RCS file: cleanup.c,v
Working file: cleanup.c
head: 1.3
branch:
locks: strict
root: 1.3
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;     selected revisions: 3
description:
unregister_chrdev to unregister the device
free the memory that is allocated to device by kfree
print no of node that is no of devices
cdev_del to delete something
—————————-
revision 1.3    locked by: root;
date: 2014/05/08 10:09:08;  author: root;  state: Exp;  lines: +0 -2
same can done in clanup function if number of nodes are more in number
—————————-
revision 1.2
date: 2014/05/08 10:05:50;  author: root;  state: Exp;  lines: +2 -0
*** empty log message ***
—————————-
revision 1.1
date: 2014/05/08 10:00:06;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: cleanup.c,v
Working file: cleanup.c
head: 1.3
branch:
“logcleanup” 58L, 1784C                                                                                                            32,1          Top
///////////////////////////////////////////////////////////////////////////////////////////////////////

CS file: init.c,v
Working file: init.c
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;     selected revisions: 2
description:
alloc_chrdev is done for registring the device
kmalloc is done to allocate memory to device
then memset is done
before kmalloc print major and minor no that are present in dev
now initilization is done means kernel provide memory
cdev_add is done to add on something
now again print major and minor no that are nor present in c_dev which is within struct sculldev
—————————-
revision 1.2    locked by: root;
date: 2014/05/08 10:06:58;  author: root;  state: Exp;  lines: +2 -3
if number of devices are more in number then use for loop
module_param is used to pass command line arguments that is number of nodes is passed by user on the shell
—————————-
revision 1.1
date: 2014/05/08 10:00:06;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: init.c,v
Working file: init.c
head: 1.2
branch:
“loginit” 58L, 2084C                                                                                                               1,0-1         Top
////////////////////////////////////////////////////////////////////////////////////////////////////////////

RCS file: dec.h,v
Working file: dec.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;     selected revisions: 1
description:
we extern node number
dev_t dev
struct sculldev *sculldev
—————————-
revision 1.1    locked by: root;
date: 2014/05/08 10:00:06;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: dec.h,v
Working file: dec.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;     selected revisions: 1
description:
we extern node number
dev_t dev

struct sculldev *sculldev
—————————-
revision 1.1    locked by: root;
date: 2014/05/08 10:00:06;  author: root;  state: Exp;
Initial revision
========================////////////////////////////////////////////////////////////

RCS file: file_op.h,v
Working file: file_op.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;     selected revisions: 1
description:
struct file_opeartion is created where mapping of open and release functon is done
include this in init functin
—————————-
revision 1.1    locked by: root;
date: 2014/05/08 10:20:54;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: file_op.h,v
Working file: file_op.h
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;     selected revisions: 1
description:
struct file_opeartion is created where mapping of open and release functon is done
include this in init functin
—————————-
//////////////////////////////////////////////////////

RCS file: header.h,v
Working file: header.h
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;     selected revisions: 2
description:
include header files that are needed in this program
struct sculldev structure is included here
that include c_dev
—————————-
revision 1.2    locked by: root;
date: 2014/05/08 10:20:29;  author: root;  state: Exp;  lines: +1 -0
defination of scullopen and scullrelease is given here
—————————-
revision 1.1
date: 2014/05/08 10:00:06;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: header.h,v
Working file: header.h
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
1,0-1         Top
total revisions: 2;     selected revisions: 2
description:
include header files that are needed in this program
struct sculldev structure is included here
that include c_dev
—————————-
revision 1.2    locked by: root;
date: 2014/05/08 10:20:29;  author: root;  state: Exp;  lines: +1 -0
defination of scullopen

////////////////////////////////////////////////////////

 

 

 

 

 

Posted in Uncategorized | Leave a comment

Character_Driver

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:
include header files that are needed in this program
struct sculldev structure is included here
that include c_dev
—————————-
revision 1.3
date: 2014/05/12 11:24:48;  author: root;  state: Exp;  lines: +16 -2
given prototype for write_function
added scullqset,device_size,data_size,quantum_size in struct sculldev.
—————————-
revision 1.2
date: 2014/05/08 10:20:29;  author: root;  state: Exp;  lines: +1 -0
defination of scullopen and scullrelease is given here
—————————-
revision 1.1
date: 2014/05/08 10:00:06;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: dec.h,v
Working file: dec.h
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 2
description:
we extern node number
dev_t dev
struct sculldev *sculldev
—————————-
revision 1.2
date: 2014/05/12 11:27:39;  author: root;  state: Exp;  lines: +4 -0
extern quantum from init file
extern device from init
extern data
extern qset from init function
—————————-
revision 1.1
date: 2014/05/08 10:00:06;  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:
alloc_chrdev is done for registring the device
kmalloc is done to allocate memory to device
then memset is done
before kmalloc print major and minor no that are present in dev
now initilization is done means kernel provide memory
cdev_add is done to add on something
now again print major and minor no that are nor present in c_dev which is within struct sculldev
—————————-
revision 1.3
date: 2014/05/12 11:26:27;  author: root;  state: Exp;  lines: +3 -0
given size for device
given size for qset
given size for quantum
—————————-
revision 1.2
date: 2014/05/08 10:06:58;  author: root;  state: Exp;  lines: +2 -3
if number of devices are more in number then use for loop
module_param is used to pass command line arguments that is number of nodes is passed by user on the shell
—————————-
revision 1.1
date: 2014/05/08 10:00:06;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: cleanup.c,v
Working file: cleanup.c
head: 1.3
branch:
locks: strict
root: 1.3
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;    selected revisions: 3
description:
unregister_chrdev to unregister the device
free the memory that is allocated to device by kfree
print no of node that is no of devices
cdev_del to delete something
—————————-
revision 1.3    locked by: root;
date: 2014/05/08 10:09:08;  author: root;  state: Exp;  lines: +0 -2
same can done in clanup function if number of nodes are more in number
—————————-
revision 1.2
date: 2014/05/08 10:05:50;  author: root;  state: Exp;  lines: +2 -0
*** empty log message ***
—————————-
revision 1.1
date: 2014/05/08 10:00:06;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: app.c,v
Working file: app.c
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 2
description:
in this function we make a application where we simply open a file
then close it
we provide node in open function to open the function created by ourself
—————————-
revision 1.2
date: 2014/05/12 11:29:53;  author: root;  state: Exp;  lines: +8 -5
changed the O_RDONLY mode to O_WRONLY in open function
write the string in the application space to the kernel
—————————-
revision 1.1
date: 2014/05/08 10:20:54;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: file_op.h,v
Working file: file_op.h
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 2
description:
struct file_opeartion is created where mapping of open and release functon is done
include this in init functin
—————————-
revision 1.2
date: 2014/05/12 11:29:31;  author: root;  state: Exp;  lines: +1 -1
done mapping for write
—————————-
revision 1.1
date: 2014/05/08 10:20:54;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: sopen.c,v
Working file: sopen.c
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 2
description:
open function is created
scullopen that have struct inode and struct file
__func__ is printed in it that gone tell us about current functin
—————————-
revision 1.2    locked by: root;
date: 2014/05/08 10:21:33;  author: root;  state: Exp;  lines: +1 -0
new struct sculldev *lscull_dev is created
container_of is done that provide the addresss of device
store that address in lscull_dev and print it
move that address to struct file private_data an print it
now assign premissions
means struct file f_flags do bitwise adding with O_ACCMODE
that provide us the mode means RDONLY,WRONLY ,RDWR
ans when we run the application .mode that is provided in open is called
—————————-
revision 1.1
date: 2014/05/08 10:20:54;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: swrite.c,v
Working file: swrite.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
printing the function name
finding the number of bytes written from the user space
using no of bytes written,finding the no of qsets required
allocate the memory for scullqset to store the data
printing the function name again
—————————-
revision 1.1    locked by: root;
date: 2014/05/12 11:31:41;  author: root;  state: Exp;
Initial revision
=============================================================================

RCS file: srelease.c,v
Working file: srelease.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
scullrelease is created that have struct inode nad struct file
—————————-
revision 1.1    locked by: root;
date: 2014/05/08 10:20:54;  author: root;  state: Exp;
Initial revision
=============================================================================

Posted in Character Driver | Leave a comment

Character driver (write performed)

RCS file: write.c,v
3 Working file: write.c
4 head: 1.1
5 branch:
6 locks: strict
7         root: 1.1
8 access list:
9 symbolic names:
10 keyword substitution: kv
11 total revisions: 1;     selected revisions: 1
12 description:
13 decllared write fxn
14 found number of qsets to be used
15 kmalloc for those qsets
16 print the string which was given in buffer of application
17 —————————-
18 revision 1.1    locked by: root;
19 date: 2014/05/12 11:45:09;  author: root;  state: Exp;
20 Initial revision
21 =============================================================================

Posted in Uncategorized | Leave a comment

charactor driver(open-release)

head 1.32;
access;
symbols;
locks; strict;
comment

1.32
date 2014.05.06.06.20.21; author root; state Exp;
branches;
next 1.31;

1.31
date 2014.05.04.09.46.22; author root; state Exp;
branches;
next 1.30;

1.30
date 2014.05.04.08.15.17; author root; state Exp;
branches;
next 1.29;

1.29
date 2014.05.04.06.32.30; author root; state Exp;
branches;
next 1.28;

1.28
date 2014.05.04.06.13.17; author root; state Exp;
branches;
next 1.27;

1.27
date 2014.05.03.12.26.38; author root; state Exp;
branches;
next 1.26;

1.26
date 2014.05.03.12.19.24; author root; state Exp;
branches;
next 1.25;

1.25
date 2014.05.03.12.01.18; author root; state Exp;
branches;
next 1.24;

1.24
date 2014.05.03.11.38.57; author root; state Exp;
branches;
next 1.23;

1.23
date 2014.05.03.10.54.49; author root; state Exp;
branches;
next 1.22;

1.22
date 2014.05.03.10.52.50; author root; state Exp;
branches;
next 1.21;

1.21
date 2014.05.03.10.51.13; author root; state Exp;
branches;
next 1.20;

1.20
date 2014.05.03.10.50.08; author root; state Exp;
branches;
next 1.19;

1.19
date 2014.05.03.10.48.38; author root; state Exp;
branches;
next 1.18;

1.18
date 2014.05.03.10.47.31; author root; state Exp;
branches;
next 1.17;

1.17
date 2014.05.03.10.37.39; author root; state Exp;
branches;
next 1.16;

1.16
date 2014.05.03.10.32.07; author root; state Exp;
branches;
next 1.15;

1.15
date 2014.05.03.10.31.14; author root; state Exp;
branches;
next 1.14;

1.14
date 2014.05.03.10.30.05; author root; state Exp;
branches;
next 1.13;

1.13
date 2014.05.03.10.28.50; author root; state Exp;
branches;
next 1.12;

1.12
date 2014.05.03.10.28.12; author root; state Exp;
branches;
next 1.11;

1.11
date 2014.05.03.10.25.22; author root; state Exp;
branches;
next 1.10;

1.10
date 2014.04.29.11.10.44; author root; state Exp;
branches;
next 1.9;

1.9
date 2014.04.29.10.38.02; author root; state Exp;
branches;
next 1.8;

1.8
date 2014.04.28.11.57.51; author root; state Exp;
branches;
next 1.7;

1.7
date 2014.04.28.11.35.48; author root; state Exp;
branches;
next 1.6;

1.6
date 2014.04.28.11.08.34; author root; state Exp;
branches;
next 1.5;

1.5
date 2014.04.28.11.07.28; author root; state Exp;
branches;
next 1.4;

1.4
date 2014.04.28.11.05.58; author root; state Exp;
branches;
next 1.3;

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

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

1.1
date 2014.04.28.08.08.28; author user3; state Exp;
branches;
next ;

desc
@driver insert function
@

1.32
log
@use module_param .
@
text
@#include”header.h”
int node;
dev_t dev;
int ret;
int major,minor;
struct sculldev *sculldev;
module_param(node,int,S_IRUGO);
static int __init device_driver_init(void)
{
printk(KERN_INFO “Emblogic Pvt. Ltd.\n”);
ret=alloc_chrdev_region(&dev, 0,node,”kamal”);
major=MAJOR(dev);
minor=MINOR(dev);
printk(KERN_INFO “%d”,major);
printk(KERN_INFO “%d”,minor);
sculldev=kmalloc(sizeof(struct sculldev),GFP_KERNEL);
return 0;

}
module_init(device_driver_init);
@

1.31
log
@*** empty log message ***
@
text
@d7 1
a16 1
//void cdev_init(struct cdev *, const struct file_operations *);
@

1.30
log
@register the driver with alloc_chrdev_region.
@
text
@d10 1
a10 1
ret=alloc_chrdev_region(&dev, 0,1,”satinder”);
@

1.29
log
@*** empty log message ***
@
text
@d2 1
a2 1
int node=5;
d7 1
a7 1
static int device_driver_init(void)
@

1.28
log
@*** empty log message ***
@
text
@a1 1
#include”decleration.h”
d6 1
d17 1
@

1.27
log
@*** empty log message ***
@
text
@d2 1
@

1.26
log
@*** empty log message ***
@
text
@d14 1
a14 1
ret=kmalloc(sizeof(struct sculldev));
@

1.25
log
@use kmalloc
@
text
@d9 5
a13 5
ret=alloc_chrdev_region(&dev, 0,1,”satinder”);
major=MAJOR(dev);
minor=MINOR(dev);
printk(KERN_INFO “%d”,major);
printk(KERN_INFO “%d”,minor);
@

1.24
log
@*** empty log message ***
@
text
@d14 1
a14 1
//ret=kmalloc(sizeof(struct sculldev));
@

1.23
log
@*** empty log message ***
@
text
@d14 2
@

1.22
log
@*** empty log message ***
@
text
@d5 1
a5 1
int major,minior;
@

1.21
log
@*** empty log message ***
@
text
@d11 1
a11 1
minior=MAJOR(dev);
d13 1
a13 1
printk(KERN_INFO “%d”,minior);
@

1.20
log
@*** empty log message ***
@
text
@d11 1
a11 1
minior=MINIOR(dev);
@

1.19
log
@*** empty log message ***
@
text
@d11 1
a11 1
minior=MAJOR(dev);
@

1.18
log
@print the major and mimior numbers.
@
text
@d12 2
a13 2
printk(KERN INFO “%d”,major);
printk(KERN INFO “%d”,minior);
@

1.17
log
@*** empty log message ***
@
text
@d5 1
d10 5
@

1.16
log
@*** empty log message ***
@
text
@d9 1
a9 1

@

1.15
log
@*** empty log message ***
@
text
@d5 1
a5 1
static int device_driver_init(void)
@

1.14
log
@*** empty log message ***
@
text
@d10 1
a10 1
module_init(device_driver);
@

1.13
log
@*** empty log message ***
@
text
@d5 1
a5 1
static int __init device_driver(void)
@

1.12
log
@*** empty log message ***
@
text
@d10 1
a10 1
module_init(device_driver_init);
@

1.11
log
@__init add in function init.
@
text
@d5 1
a5 1
static int __init device_driver_init(void)
@

1.10
log
@register the driver.
@
text
@d5 1
a5 1
static int device_driver_init(void)
d7 3
a9 8
printk(KERN_INFO “Emblogic Pvt. Ltd.\n”);
ret=alloc_chrdev_region(&dev, 0,1,”satinder”);
//if(ret)
//{
//printk(KERN_INFO “RET=%d”,ret);
//}
return 0;
}
@

1.9
log
@*** empty log message ***
@
text
@d3 2
d8 1
a8 1
//ret=alloc_chrdev_region(&dev, unsigned, unsigned, “satinder”);
@

1.8
log
@define the int dev.
@
text
@a2 1
int dev;
d6 5
a10 5
ret=alloc_chrdev_region(&dev, unsigned, unsigned, “satinder”);
if(ret)
{
printk(KERN_INFO “RET=%d”,ret);
}
@

1.7
log
@register the driver.
@
text
@d3 1
@

1.6
log
@*** empty log message ***
@
text
@d6 5
@

1.5
log
@defined int node.
@
text
@d2 1
a4 1
int node=5;
@

1.4
log
@remove the decleration.h file
@
text
@d4 1
a4 1
node=5;
@

1.3
log
@give the value to the node.
@
text
@a1 1
#include”decleration.h”
@

1.2
log
@*** empty log message ***
@
text
@d2 1
d5 2
a6 1
printk(KERN_INFO “Emblogic Pvt. Ltd.\n”);
@

1.1
log
@Initial revision
@
text
@d4 1
a4 1
printk(KERN_INFO “HELLO KERNAL I AM NEW DRIVER”);
@

Posted in Uncategorized | Leave a comment

character driver

RCS file: init.c,v
Working file: init.c
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 2
description:
driver is inserted and registered in kernel space. driver is initialized and add by using cdev_init and cdev_add.
major and minor no.s are printed.
—————————-
revision 1.2    locked by: root;
date: 2014/05/12 11:01:10;  author: root;  state: Exp;  lines: +6 -1
parameters are taken from the user to calculate the no. of scullqset.
—————————-
revision 1.1
date: 2014/05/08 10:04:44;  author: root;  state: Exp;
Initial revision
=============================================================================
RCS file: cleanup.c,v
Working file: cleanup.c
head: 1.1
branch:
locks: strict
root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
unregister is done here……….kfree is used to free the memory.
—————————-
revision 1.1    locked by: root;
date: 2014/05/08 10:04:50;  author: root;  state: Exp;
Initial revision
=============================================================================
RCS file: open.c,v
Working file: open.c
head: 1.2
branch:
locks: strict
root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 2
description:
this is the program to open the device and function performing here.
—————————-
revision 1.2    locked by: root;
date: 2014/05/12 11:02:23;  author: root;  state: Exp;  lines: +2 -2
*** empty log message ***
—————————-
revision 1.1
date: 2014/05/08 10:04:59;  author: root;  state: Exp;
Initial revision
=============================================================================
RCS file: release.c,v
Working file: release.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 the program to release the device
—————————-
revision 1.1    locked by: root;
date: 2014/05/08 10:05:04;  author: root;  state: Exp;
Initial revision
=============================================================================
RCS file: swrite.c,v
Working file: swrite.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 the function to write the data into the buffer.
—————————-
revision 1.1    locked by: root;
date: 2014/05/12 11:02:47;  author: root;  state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

It is always a good practice to assign a NULL value to a pointer variable in case you do not have exact address to be assigned. This is done at the time of variable declaration. A pointer that is assigned NULL is called a null pointer.

The NULL pointer is a constant with a value of zero defined in several standard libraries ex.-

On most of the operating systems, programs are not permitted to access memory at address 0 because that memory is reserved by the operating system. However, the memory address 0 has special significance; it signals that the pointer is not intended to point to an accessible memory location. But by convention, if a pointer contains the null (zero) value, it is assumed to point to nothing.

Posted in Data Structures with C | Leave a comment

about fifo

Definition:
A FIFO is similar to a pipe. A FIFO (First In First Out) is a one-way flow of data. FIFOs have a name, so
unrelated processes can share the FIFO. FIFO is a named pipe. This is the main difference between pipes
and FIFOs.
Creat: A FIFO is created by the mkfifo function:
#include <sys/types.h>
#include <sys/stat.h>
int mkfifo(const char *pathname, mode_t mode);
pathname – a UNIX pathname (path and filename). The name of the FIFO
mode – the file permission bits.
FIFO can also be created by the mknod system call,
e.g., mknod(“fifo1”, S_IFIFO|0666, 0) is same as mkfifo(“fifo1”, 0666).
Open: mkfifo tries to create a new FIFO. If the FIFO already exists, then an EEXIST error is returned. To
open an existing FIFO, use open(), fopen() or freopen()
Close: to close an open FIFO, use close(). To delete a created FIFO, use unlink().
Properties: ( Some of them are also applicable to PIPES)
1) After a FIFO is created, it can be opened for read or write.
2) Normally, opening a FIFO for read or write, it blocks until another process opens it for write or read.
3) A read gets as much data as it requests or as much data as the FIFO has, whichever is less.
4) A write to a FIFO is atomic, as long as the write does not exceed the capacity of the FIFO. The
capacity is at least 4k1.
1
Why?
(1)The main operations (system calls) on PIPE or FIFO are write(…,length) and read(…,length).
(2)The length of write() or read() should not exceed 4k if we want the code portable among different unix systems.
(3) That is, all systems should guarantee write(…,length) or read(…,length) correctly executable when length <= 4k.
(4) Accordingly, the capacity of PIPE/FIFO should be at least 4k.
(5) Statements 1 and 2 are excerpted from textbooks.
5) One step further :How to verify the minimum capacity of a FIFO ? I have verified that the
capacity of a PIPE or a FIFO on my Unix System is 9k.
6) Blocked if read from an empty FIFO, or write to a full FIFO.
7) The O_NDELAY flag or O_NONBLOCK flag can be set for FIFO to affect the behavior of various
operations. This prevents accesses to the FIFO from blocking. See the Table below.
Example: how to set the flags?
writefd=open(FIFO1, O_WRONLY | O_NONBLOCK, 0);

Posted in Uncategorized | Leave a comment

file i/o(changing the existing password in a file )

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main()
{
char *pwd=NULL;
char *pwd1=NULL;
int ch=0,i=0,ret,len;
char *buff;
pwd=malloc(sizeof(char) *10);
pwd1=malloc(sizeof(char) *10);
buff=malloc(sizeof(char) *10);
FILE *fptr = NULL;
fptr=fopen(“hello.txt”,”r+”);
if(fptr == NULL)
{
perror(“fopen”);
return -1;
}
else
printf(“file is opened successfully\n”);
printf(“enter old password\n”);
gets(pwd);
ch=getc(fptr);
while(ch!=EOF)
{
if(ch!=’\n’)
{
buff[i]=ch;
ch=getc(fptr);
i++;
}
else
{
ret=strcmp(buff,pwd);
if(ret==0)
{
printf(“\nenter new password::”);
gets(pwd);
printf(“\nconfirm password::”);
gets(pwd1);
ret=strcmp(pwd,pwd1);
while(ret!=0)
{
for(i=0;i<3;i++)
{
printf(“both passwords are not same\n”);
printf(“enter the confirm password again::”);
gets(pwd1);
ret=strcmp(pwd,pwd1);
}
printf(“u have tried maximum times..\n Try again after some time\n”);
break;
}
if(ret==0)
{
len=strlen(pwd1);
ret=fseek(fptr,-(len+1),SEEK_CUR);
ret=fputs(pwd1,fptr);
ret=fputc(‘\n’,fptr);
printf(“\npassword changed..\n”);
}
}
else
{
i=0;
ch=fgetc(fptr);
}
}
}
return 0;
}

Posted in Uncategorized | Leave a comment

C Runtime Errors

C runtime errors are those errors that occur during the execution of a c program and generally occur due to some illegal operation performed in the program.

Examples of some illegal operations that may produce runtime errors are:

Dividing a number by zero
Trying to open a file which is not created
Lack of free memory space

It should be noted that occurrence of these errors may stop program execution, thus to encounter this, a program should be written such that it is able to handle such unexpected errors and rather than terminating unexpectedly, it should be able to continue operating. This ability of the program is known as robustness and the code used to make a program robust is known as guard code as it guards program from terminating abruptly due to occurrence of execution errors.

Posted in Uncategorized | Leave a comment