EmbLogic | Embedded System and ARM Training

Charecter Driver log file

Posted on July 28, 2013 by sampath.kumar

RCS file: ./basicregister.c,v
Working file: basicregister.c
head: 1.31
branch:
locks: strict
sampath: 1.22
sampath: 1.31
access list:
symbolic names:
keyword substitution: kv
total revisions: 31; selected revisions: 31
description:
Base program for driver
Registering the driver into the kernel using register_chrdev
inserting the module using insmod
unregistering using unregister_chrdev
removing the module using rmmod
—————————-
revision 1.31 locked by: sampath;
date: 2013/07/28 12:22:25; author: sampath; state: Exp; lines: +43 -2
Implementation of proc
calling create_proc_read_entry
mapping function which contain sculldev Information device name,major number allocated,quantum size, qset size, no of bytes written and read by application
Able to access from proc directory
—————————-
revision 1.30
date: 2013/07/28 06:42:14; author: sampath; state: Exp; lines: +16 -3
Implementation of spinlock for synchronization
initialized spin_lock_init and locking using spin_lock in open
unlocking at the end of read using spin_unlock
Also tested synchronization using spin_lock_irq and spin_unlock_irq
spin_lock_irqsave and spin_lock_irqrestore
synchronizing using spinlock and completion
—————————-
revision 1.29
date: 2013/07/27 19:26:57; author: sampath; state: Exp; lines: +16 -8
Initialized sema_init and init_completion in open within if condition if(opened in write only mode) as the application level has calling open twice once in write and second in read only mode
removed declaring sem_post in close and declared at the end of read so as to allow another application to open afetr first application complete reading operation
note: care should be taken as open and close are called twice from same application
—————————-
revision 1.28
date: 2013/07/25 06:49:48; author: sampath; state: Exp; lines: +14 -6
Implemented completion
declared init_completion in open
wait_for_completion in read
completion in write
—————————-
revision 1.27
date: 2013/07/24 15:45:58; author: sampath; state: Exp; lines: +51 -10
Corrected memory allocation error for scull_Qset
Initialised scull_dev[lv]->scull_Qset=NULL for all lv values
Able to perform trimming operation correctly
Implementation of sema_init is done
Able to synchronize correctly for multi applications
Tested for 3 applications
—————————-
revision 1.26
date: 2013/07/22 14:05:23; author: sampath; state: Exp; lines: +7 -1
done with implementation of semaphores sema_init
using down and up
able to synchronize correctly tested running 3 applications at once
—————————-
revision 1.25
date: 2013/07/22 12:27:19; author: sampath; state: Exp; lines: +76 -8
Scull trim Implementation done if application opens in write only mode
sucessfully trimming required no of quantum upto required no of bytes
—————————-
revision 1.24
date: 2013/07/19 07:23:36; author: sampath; state: Exp; lines: +35 -75
Sucessfully tested driver using 3 multithreaded application one at a time
Able to write and read data sucessfully
Trying to synchronize multiple application running at ones
—————————-
revision 1.23
date: 2013/07/17 05:19:21; author: sampath; state: Exp; lines: +75 -28
Defined llseek function mapped from function call
Able to read data from application according to lseek offset in application
done with read operation using lseek
—————————-
revision 1.22 locked by: sampath;
date: 2013/07/13 11:04:51; author: sampath; state: Exp; lines: +15 -54
done with read and write operations for multiple scullqsets
—————————-
revision 1.21
date: 2013/07/13 10:43:24; author: sampath; state: Exp; lines: +1 -1
added ubuff+tnobsr in copy_to_user for cursor position
able to read data at the application
—————————-
revision 1.20
date: 2013/07/13 10:17:59; author: sampath; state: Exp; lines: +35 -26
sucessfully Implemented reading operation for 98 bytes of data
able to read tnobsr in application
—————————-
revision 1.19
date: 2013/07/13 07:17:49; author: sampath; state: Exp; lines: +20 -13
new
—————————-
revision 1.18
date: 2013/07/13 04:52:08; author: sampath; state: Exp; lines: +49 -36
Able to read 63 bytes of data from kernel to user buffer.
verification done by returning tnobsr to user application.
—————————-
revision 1.17
date: 2013/07/12 08:12:41; author: sampath; state: Exp; lines: +80 -11
Implemented read operation trying to read from kernel to user buffer using copy_to_user
Able to read only 8bytes of data
tryin g to implement for complete read operation for reading 100bytes
—————————-
revision 1.16
date: 2013/07/11 20:56:23; author: sampath; state: Exp; lines: +5 -10
Able to return 0 from read operation of kernel buffer to application
—————————-
revision 1.15
date: 2013/07/11 20:10:35; author: sampath; state: Exp; lines: +34 -25
Sucessfully implemented for multiple qsets
Tested writing operation for 100 bytes of data
no of scull qset are 2 and no of quantums created are 13
—————————-
revision 1.14
date: 2013/07/11 11:12:47; author: sampath; state: Exp; lines: +33 -10
sucessfully implemented write operation for multiple quantums
able to automate correct no of quantums
—————————-
revision 1.13
date: 2013/07/11 07:57:21; author: sampath; state: Exp; lines: +24 -7
Sucessfully implemented write operation
using kernel facility copy_from_user
testing for only 4bytes of data for which one quantum is enough
—————————-
revision 1.12
date: 2013/07/10 11:43:26; author: sampath; state: Exp; lines: +75 -21
Implementation of scullqset, qset and quantum done
automated number of scullqsets and quantums wrt the application
—————————-
revision 1.11
date: 2013/07/10 03:53:40; author: sampath; state: Exp; lines: +120 -34
Implemeenting write operation
fetched private->data to sculldev
Implemented auto calculation for number of scull_qset and number of quantums
allocated memory for scull_qset qset and quantum calling their functions separately and trying to link them
—————————-
revision 1.10
date: 2013/07/09 07:28:58; author: sampath; state: Exp; lines: +22 -0
Implemented basic write and read operations
—————————-
revision 1.9
date: 2013/07/08 07:27:12; author: sampath; state: Exp; lines: +39 -41
Implementation of scull_trim for future use
—————————-
revision 1.8
date: 2013/07/05 04:53:38; author: sampath; state: Exp; lines: +1 -1
Initialised cdev_del after completing the usage of cdev
—————————-
revision 1.7
date: 2013/07/05 04:51:02; author: sampath; state: Exp; lines: +9 -8
Added ret_cdev to check the return value of cdev_add
—————————-
revision 1.6
date: 2013/07/04 13:07:35; author: sampath; state: Exp; lines: +17 -7
Initialising multiple devices
assining dev using MKDEV
—————————-
revision 1.5
date: 2013/07/04 11:03:31; author: sampath; state: Exp; lines: +23 -10
memory mapping through container_of
pointing scull through inode
—————————-
revision 1.4
date: 2013/07/03 10:49:38; author: sampath; state: Exp; lines: +19 -2
Assigning values to members of sculldev in scullinit and printing
—————————-
revision 1.3
date: 2013/07/02 13:40:19; author: sampath; state: Exp; lines: +17 -2
Initialised function for scull_open
and scull close
calling open function from application
communicating from user spaceapplication to kernelspace driver
—————————-
revision 1.2
date: 2013/07/02 10:34:24; author: sampath; state: Exp; lines: +44 -4
Implemented struct scull
registering the device in device table
Initialized cdev_init
pointing to dev through cdev
—————————-
revision 1.1
date: 2013/07/01 07:16:06; author: sampath; state: Exp;
Initial revision
=============================================================================

Posted in Character Driver, Uncategorized | Tagged prabjot | Leave a comment

CHARACTER DEVICE DRIVER

Posted on July 26, 2013 by amit.dalal

i have successfully implimented the semaphore in kernel level and complition in kernel level

RCS file: app11.c,v
Working file: app11.c
head: 1.1
branch:
locks: strict
amitdalal: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
define set_sem_val function
define semaphore_p and semaphore_v
done this for all 5 applicatin
—————————-
revision 1.1 locked by: amitdalal;
date: 2013/07/25 23:29:38; author: amitdalal; state: Exp;
Initial revision
=============================================================================

RCS file: amit.c,v
Working file: amit.c
head: 1.18
branch:
locks: strict
amitdalal: 1.18
access list:
symbolic names:
keyword substitution: kv
total revisions: 18; selected revisions: 18
description:
added function of copy from user
printk the no of byte writen successfully for one quantum
—————————-
revision 1.18 locked by: amitdalal;
date: 2013/07/26 00:33:49; author: amitdalal; state: Exp; lines: +9 -19
use wait_for_complition in read
use complete_all in write
—————————-
revision 1.17
date: 2013/07/25 23:23:36; author: amitdalal; state: Exp; lines: +9 -8
initialise sem_init again
—————————-
revision 1.16
date: 2013/07/25 23:02:12; author: amitdalal; state: Exp; lines: +33 -11
initialise two semaphore for read and write in sculldev initialisation
down semaphore in write for write
at the end up semaphore for read
down semaphore in write for read
at the end up semaphore for write
—————————-
revision 1.15
date: 2013/07/22 22:47:17; author: amitdalal; state: Exp; lines: +5 -5
initialise the semaphore init in scull_open for kernel level synchronisation
call down_interruptible in open
call up in release function
define trim function
calculate nosqs and noq agin in trim function
memset the quantum_size
to free all quantum
—————————-
revision 1.14
date: 2013/07/22 22:07:46; author: amitdalal; state: Exp; lines: +102 -40
define fpos variable for fetching file position in read
add fpos to count to calculate the nosqs and noq
—————————-
revision 1.13
date: 2013/07/17 00:08:24; author: amitdalal; state: Exp; lines: +0 -1
added some variable for write using llseek
added bpos for position update in copy from user
define bpos flag
—————————-
revision 1.12
date: 2013/07/17 00:07:11; author: amitdalal; state: Exp; lines: +0 -1
added variable bpos for position
use flag and j
—————————-
revision 1.11
date: 2013/07/17 00:02:29; author: amitdalal; state: Exp; lines: +0 -2
added some variable for reading using llseek
fix the problem related with left out of some first character
—————————-
revision 1.10
date: 2013/07/16 23:37:14; author: amitdalal; state: Exp; lines: +244 -194
give call to llseek
define function llseek
—————————-
revision 1.9
date: 2013/07/15 21:52:06; author: amitdalal; state: Exp; lines: +67 -41
added loff_t function to .c file
use f_pos for storing the value of pos
—————————-
revision 1.8
date: 2013/07/11 17:37:19; author: amitdalal; state: Exp; lines: +53 -38
modified code for write to get required no of qset
add lnoq variable
—————————-
revision 1.7
date: 2013/07/11 06:05:24; author: amitdalal; state: Exp; lines: +0 -1
add loop variable in loop for reading
remove some bug in reading loop
—————————-
revision 1.6
date: 2013/07/11 05:37:03; author: amitdalal; state: Exp; lines: +4 -4
remove some bug from write function
added loop variable to specify no of quantum in 2nd qset
—————————-
revision 1.5
date: 2013/07/11 05:18:10; author: amitdalal; state: Exp; lines: +76 -16
creating read function
use copy to user function
modifing the copy to user function
—————————-
revision 1.4
date: 2013/07/11 00:41:53; author: amitdalal; state: Exp; lines: +1 -0
debbuging problem causing kernel crash
—————————-
revision 1.3
date: 2013/07/11 00:19:58; author: amitdalal; state: Exp; lines: +11 -7
added variable loop
use while loop for creating multiple qset
—————————-
revision 1.2
date: 2013/07/11 00:00:36; author: amitdalal; state: Exp; lines: +25 -4
added the function of quantum written for 8 byte
debugging the problem related to writting of data not 8 byte
fix problem successfully related to written
—————————-
revision 1.1
date: 2013/07/10 21:22:34; author: amitdalal; state: Exp;
Initial revision
=============================================================================

RCS file: dd1,v
Working file: dd1
head: 1.5
branch:
locks: strict
amitdalal: 1.5
access list:
symbolic names:
keyword substitution: kv
total revisions: 5; selected revisions: 5
description:
adding compilation command for reading in script
gcc
./app1
—————————-
revision 1.5 locked by: amitdalal;
date: 2013/07/25 23:26:50; author: amitdalal; state: Exp; lines: +16 -2
run the 5 application simutanously
—————————-
revision 1.4
date: 2013/07/18 21:17:28; author: amitdalal; state: Exp; lines: +1 -1
added -lpthread for compilation
—————————-
revision 1.3
date: 2013/07/15 21:55:17; author: amitdalal; state: Exp; lines: +4 -3
add unlink node
—————————-
revision 1.2
date: 2013/07/11 06:00:23; author: amitdalal; state: Exp; lines: +2 -2
make another node for reading
—————————-
revision 1.1
date: 2013/07/11 05:16:48; author: amitdalal; state: Exp;
Initial revision
=============================================================================

RCS file: header.h,v
Working file: header.h
head: 1.7
branch:
locks: strict
amitdalal: 1.7
access list:
symbolic names:
keyword substitution: kv
total revisions: 7; selected revisions: 7
description:
added asm header .h for copy from user
—————————-
revision 1.7 locked by: amitdalal;
date: 2013/07/26 00:38:59; author: amitdalal; state: Exp; lines: +3 -3
define macro for complition in header.h
another way is to define the complition in sculldev
—————————-
revision 1.6
date: 2013/07/25 23:25:01; author: amitdalal; state: Exp; lines: +9 -3
include struct semaphore rsem and wsem in sculldev
—————————-
revision 1.5
date: 2013/07/22 22:12:52; author: amitdalal; state: Exp; lines: +3 -1
defined header file for semaphore in kernel level
define semaphore in Sculldev structure
—————————-
revision 1.4
date: 2013/07/16 23:38:48; author: amitdalal; state: Exp; lines: +7 -7
include prototype of llseek
define llseek in file operation
—————————-
revision 1.3
date: 2013/07/15 21:53:32; author: amitdalal; state: Exp; lines: +5 -2
give prototype of llseek
define it in file operation
—————————-
revision 1.2
date: 2013/07/11 17:39:26; author: amitdalal; state: Exp; lines: +5 -5
remove init and cleanup prototype
—————————-
revision 1.1
date: 2013/07/10 21:25:25; author: amitdalal; state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Tagged prabjot | Leave a comment

VARIABLES IN SHELL SCRIPT

Posted on July 25, 2013 by Prabhjot

In bash every variable is a string..
My question is if these values are stored as ASCII values?

And how arithmetic operations are manipulated with integers/numbers, if they are stored as strings(or ASCII values)????

Posted in Shell Scripts | Leave a comment

Charecter Driver log_file

Posted on July 24, 2013 by sampath.kumar

RCS file: ./basicregister.c,v
Working file: basicregister.c
head: 1.27
branch:
locks: strict
sampath: 1.22
sampath: 1.27
access list:
symbolic names:
keyword substitution: kv
total revisions: 27; selected revisions: 27
description:
Base program for driver
Registering the driver into the kernel using register_chrdev
inserting the module using insmod
unregistering using unregister_chrdev
removing the module using rmmod
—————————-
revision 1.27 locked by: sampath;
date: 2013/07/24 09:28:01; author: sampath; state: Exp; lines: +48 -9
Corrected memory allocation error for scullqset
correscted errors in trimming able to trim correct no of bytes
sema_init implementation done
synchronizing correctly for multithreadded application
tested for 3 applications
—————————-
revision 1.26
date: 2013/07/22 14:05:23; author: sampath; state: Exp; lines: +7 -1
done with implementation of semaphores sema_init
using down and up
able to synchronize correctly tested running 3 applications at once
—————————-
revision 1.25
date: 2013/07/22 12:27:19; author: sampath; state: Exp; lines: +76 -8
Scull trim Implementation done if application opens in write only mode
sucessfully trimming required no of quantum upto required no of bytes
—————————-
revision 1.24
date: 2013/07/19 07:23:36; author: sampath; state: Exp; lines: +35 -75
Sucessfully tested driver using 3 multithreaded application one at a time
Able to write and read data sucessfully
Trying to synchronize multiple application running at ones
—————————-
revision 1.23
date: 2013/07/17 05:19:21; author: sampath; state: Exp; lines: +75 -28
Defined llseek function mapped from function call
Able to read data from application according to lseek offset in application
done with read operation using lseek
—————————-
revision 1.22 locked by: sampath;
date: 2013/07/13 11:04:51; author: sampath; state: Exp; lines: +15 -54
done with read and write operations for multiple scullqsets
—————————-
revision 1.21
date: 2013/07/13 10:43:24; author: sampath; state: Exp; lines: +1 -1
added ubuff+tnobsr in copy_to_user for cursor position
able to read data at the application
—————————-
revision 1.20
date: 2013/07/13 10:17:59; author: sampath; state: Exp; lines: +35 -26
sucessfully Implemented reading operation for 98 bytes of data
able to read tnobsr in application
—————————-
revision 1.19
date: 2013/07/13 07:17:49; author: sampath; state: Exp; lines: +20 -13
new
—————————-
revision 1.18
date: 2013/07/13 04:52:08; author: sampath; state: Exp; lines: +49 -36
Able to read 63 bytes of data from kernel to user buffer.
verification done by returning tnobsr to user application.
—————————-
revision 1.17
date: 2013/07/12 08:12:41; author: sampath; state: Exp; lines: +80 -11
Implemented read operation trying to read from kernel to user buffer using copy_to_user
Able to read only 8bytes of data
tryin g to implement for complete read operation for reading 100bytes
—————————-
revision 1.16
date: 2013/07/11 20:56:23; author: sampath; state: Exp; lines: +5 -10
Able to return 0 from read operation of kernel buffer to application
—————————-
revision 1.15
date: 2013/07/11 20:10:35; author: sampath; state: Exp; lines: +34 -25
Sucessfully implemented for multiple qsets
Tested writing operation for 100 bytes of data
no of scull qset are 2 and no of quantums created are 13
—————————-
revision 1.14
date: 2013/07/11 11:12:47; author: sampath; state: Exp; lines: +33 -10
sucessfully implemented write operation for multiple quantums
able to automate correct no of quantums
—————————-
revision 1.13
date: 2013/07/11 07:57:21; author: sampath; state: Exp; lines: +24 -7
Sucessfully implemented write operation
using kernel facility copy_from_user
testing for only 4bytes of data for which one quantum is enough
—————————-
revision 1.12
date: 2013/07/10 11:43:26; author: sampath; state: Exp; lines: +75 -21
Implementation of scullqset, qset and quantum done
automated number of scullqsets and quantums wrt the application
—————————-
revision 1.11
date: 2013/07/10 03:53:40; author: sampath; state: Exp; lines: +120 -34
Implemeenting write operation
fetched private->data to sculldev
Implemented auto calculation for number of scull_qset and number of quantums
allocated memory for scull_qset qset and quantum calling their functions separately and trying to link them
—————————-
revision 1.10
date: 2013/07/09 07:28:58; author: sampath; state: Exp; lines: +22 -0
Implemented basic write and read operations
—————————-
revision 1.9
date: 2013/07/08 07:27:12; author: sampath; state: Exp; lines: +39 -41
Implementation of scull_trim for future use
—————————-
revision 1.8
date: 2013/07/05 04:53:38; author: sampath; state: Exp; lines: +1 -1
Initialised cdev_del after completing the usage of cdev
—————————-
revision 1.7
date: 2013/07/05 04:51:02; author: sampath; state: Exp; lines: +9 -8
Added ret_cdev to check the return value of cdev_add
—————————-
revision 1.6
date: 2013/07/04 13:07:35; author: sampath; state: Exp; lines: +17 -7
Initialising multiple devices
assining dev using MKDEV
—————————-
revision 1.5
date: 2013/07/04 11:03:31; author: sampath; state: Exp; lines: +23 -10
memory mapping through container_of
pointing scull through inode
—————————-
revision 1.4
date: 2013/07/03 10:49:38; author: sampath; state: Exp; lines: +19 -2
Assigning values to members of sculldev in scullinit and printing
—————————-
revision 1.3
date: 2013/07/02 13:40:19; author: sampath; state: Exp; lines: +17 -2
Initialised function for scull_open
and scull close
calling open function from application
communicating from user spaceapplication to kernelspace driver
—————————-
revision 1.2
date: 2013/07/02 10:34:24; author: sampath; state: Exp; lines: +44 -4
Implemented struct scull
registering the device in device table
Initialized cdev_init
pointing to dev through cdev
—————————-
revision 1.1
date: 2013/07/01 07:16:06; author: sampath; state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

CHARACTER DRIVER

Posted on July 23, 2013 by amit.dalal

i have successfully implimented the mutex with in the 1 application and semaphore with in the thread for 4 application and done semaphore within the kernel level it is suceesssfully running

RCS file: app11.c,v
Working file: app11.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
use mutex for inter thread communication
initialise mutex in main app11 function
use mutex_lock
use mutex_unlock for one application app11
—————————-
revision 1.1
date: 2013/07/22 22:16:09; author: amitdalal; state: Exp;
Initial revision
=============================================================================

RCS file: amit.c,v
Working file: amit.c
head: 1.15
branch:
locks: strict
amitdalal: 1.15
access list:
symbolic names:
keyword substitution: kv
total revisions: 15; selected revisions: 15
description:
added function of copy from user
printk the no of byte writen successfully for one quantum
—————————-
revision 1.15 locked by: amitdalal;
date: 2013/07/22 22:47:17; author: amitdalal; state: Exp; lines: +5 -5
initialise the semaphore init in scull_open for kernel level synchronisation
call down_interruptible in open
call up in release function
define trim function
calculate nosqs and noq agin in trim function
memset the quantum_size
to free all quantum
—————————-
revision 1.14
date: 2013/07/22 22:07:46; author: amitdalal; state: Exp; lines: +102 -40
define fpos variable for fetching file position in read
add fpos to count to calculate the nosqs and noq
—————————-
revision 1.13
date: 2013/07/17 00:08:24; author: amitdalal; state: Exp; lines: +0 -1
added some variable for write using llseek
added bpos for position update in copy from user
define bpos flag
—————————-
revision 1.12
date: 2013/07/17 00:07:11; author: amitdalal; state: Exp; lines: +0 -1
added variable bpos for position
use flag and j
—————————-
revision 1.11
date: 2013/07/17 00:02:29; author: amitdalal; state: Exp; lines: +0 -2
added some variable for reading using llseek
fix the problem related with left out of some first character
—————————-
revision 1.10
date: 2013/07/16 23:37:14; author: amitdalal; state: Exp; lines: +244 -194
give call to llseek
define function llseek
—————————-
revision 1.9
date: 2013/07/15 21:52:06; author: amitdalal; state: Exp; lines: +67 -41
added loff_t function to .c file
use f_pos for storing the value of pos
—————————-
revision 1.8
date: 2013/07/11 17:37:19; author: amitdalal; state: Exp; lines: +53 -38
modified code for write to get required no of qset
add lnoq variable
—————————-
revision 1.7
date: 2013/07/11 06:05:24; author: amitdalal; state: Exp; lines: +0 -1
add loop variable in loop for reading
remove some bug in reading loop
—————————-
revision 1.6
date: 2013/07/11 05:37:03; author: amitdalal; state: Exp; lines: +4 -4
remove some bug from write function
added loop variable to specify no of quantum in 2nd qset
—————————-
revision 1.5
date: 2013/07/11 05:18:10; author: amitdalal; state: Exp; lines: +76 -16
creating read function
use copy to user function
modifing the copy to user function
—————————-
revision 1.4
date: 2013/07/11 00:41:53; author: amitdalal; state: Exp; lines: +1 -0
debbuging problem causing kernel crash
—————————-
revision 1.3
date: 2013/07/11 00:19:58; author: amitdalal; state: Exp; lines: +11 -7
added variable loop
use while loop for creating multiple qset
—————————-
revision 1.2
date: 2013/07/11 00:00:36; author: amitdalal; state: Exp; lines: +25 -4
added the function of quantum written for 8 byte
debugging the problem related to writting of data not 8 byte
fix problem successfully related to written
—————————-
revision 1.1
date: 2013/07/10 21:22:34; author: amitdalal; state: Exp;
Initial revision
=============================================================================

RCS file: dd1,v
Working file: dd1
head: 1.9
branch:
locks: strict
amitdalal: 1.9
access list:
symbolic names:
keyword substitution: kv
total revisions: 5; selected revisions: 5
description:
adding compilation command for reading in script
gcc
./app1
—————————-
revision 1.9 locked by: amitdalal;
date: 2013/07/21 22:56:36; author: amitdalal; state: Exp; lines: +8 -0
added gcc command for 5 application
added executable command for all the 5 application
—————————-
revision 1.8
date: 2013/07/18 21:17:28; author: amitdalal; state: Exp; lines: +1 -1
added -lpthread for compilation
—————————-
revision 1.7
date: 2013/07/15 21:55:17; author: amitdalal; state: Exp; lines: +4 -3
add unlink node
—————————-
revision 1.6
date: 2013/07/11 06:00:23; author: amitdalal; state: Exp; lines: +2 -2
make another node for reading
—————————-
revision 1.5
date: 2013/07/11 05:16:48; author: amitdalal; state: Exp;
Initial revision
=============================================================================
RCS file: dd1,v
Working file: dd1
head: 1.4
branch:
locks: strict
amitdalal: 1.4
access list:
symbolic names:
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
adding compilation command for reading in script
gcc
./app1
—————————-
revision 1.4 locked by: amitdalal;
date: 2013/07/19 21:17:28; author: amitdalal; state: Exp; lines: +1 -1
added -lpthread for compilation
—————————-
revision 1.3
date: 2013/07/15 21:55:17; author: amitdalal; state: Exp; lines: +4 -3
add unlink node
—————————-
revision 1.2
date: 2013/07/11 06:00:23; author: amitdalal; state: Exp; lines: +2 -2
make another node for reading
—————————-
revision 1.1
date: 2013/07/11 05:16:48; author: amitdalal; state: Exp;
Initial revision
=============================================================================
:
RCS file: header.h,v
Working file: header.h
head: 1.5
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 5; selected revisions: 5
description:
added asm header .h for copy from user
—————————-
revision 1.5
date: 2013/07/22 22:12:52; author: amitdalal; state: Exp; lines: +3 -1
defined header file for semaphore in kernel level
define semaphore in Sculldev structure
—————————-
revision 1.4
date: 2013/07/16 23:38:48; author: amitdalal; state: Exp; lines: +7 -7
include prototype of llseek
define llseek in file operation
—————————-
revision 1.3
date: 2013/07/15 21:53:32; author: amitdalal; state: Exp; lines: +5 -2
give prototype of llseek
define it in file operation
—————————-
revision 1.2
date: 2013/07/11 17:39:26; author: amitdalal; state: Exp; lines: +5 -5
remove init and cleanup prototype
—————————-
revision 1.1
date: 2013/07/10 21:25:25; author: amitdalal; state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Tagged prabjot | Leave a comment

CHARACTER DEVICE DRIVER

Posted on July 22, 2013 by amit.dalal

i have implimented the read write close open for 5 application in multithread using semaphore successfully.now i am going to do trim function………………………..

RCS file: app.c,v
Working file: app.c
head: 1.9
branch:
locks: strict
amitdalal: 1.9
access list:
symbolic names:
keyword substitution: kv
total revisions: 9; selected revisions: 9
description:
extended the message in buff
—————————-
revision 1.9 locked by: amitdalal;
date: 2013/07/21 22:38:57; author: amitdalal; state: Exp; lines: +127 -73
include some header file for ipc semaphore and thread semaphore
give the prototype of set sem_value
give prototype for semaphore_p and semaphore_v
defined union semun structure
created ipc semaphore for ist application
call the function set_sem_value
call the function semaphore _p
call the function semaphore_v at te end of main finction
defined semaphor_p,semaphore_v and set_sem_val function
same step are done for 5 application except calling set_value function
—————————-
revision 1.8
date: 2013/07/18 21:16:18; author: amitdalal; state: Exp; lines: +0 -1
added pthread join function
added pthread exit
—————————-
revision 1.7
date: 2013/07/18 21:08:19; author: amitdalal; state: Exp; lines: +94 -41
define the function for open
4 thread created
define the function for write
lssek function after write
define function for read
define function for close
—————————-
revision 1.6
date: 2013/07/17 21:37:34; author: amitdalal; state: Exp; lines: +8 -5
added variable len0,count0 for lseek after write
added lseek after write
again use the write function to append
—————————-
revision 1.5
date: 2013/07/17 00:11:50; author: amitdalal; state: Exp; lines: +0 -1
added variable
use lseek
update write
printk offset value
—————————-
revision 1.4
date: 2013/07/16 23:40:05; author: amitdalal; state: Exp; lines: +71 -68
include header file for lseek
set the offset
printf the value of offset
—————————-
revision 1.3
date: 2013/07/15 21:56:21; author: amitdalal; state: Exp; lines: +52 -15
added lseek for f_pos
printf the newpos
—————————-
revision 1.2
date: 2013/07/11 00:32:38; author: amitdalal; state: Exp; lines: +1 -1
extended the message to check whether my multiple qset is working or not for above 64 byte
—————————-
revision 1.1
date: 2013/07/11 00:04:48; author: amitdalal; state: Exp;
Initial revision
=============================================================================
RCS file: dd1,v
Working file: dd1
head: 1.5
branch:
locks: strict
amitdalal: 1.5
access list:
symbolic names:
keyword substitution: kv
total revisions: 5; selected revisions: 5
description:
adding compilation command for reading in script
gcc
./app1
—————————-
revision 1.5 locked by: amitdalal;
date: 2013/07/21 22:56:36; author: amitdalal; state: Exp; lines: +8 -0
added gcc command for 5 application
added executable command for all the 5 application
—————————-
revision 1.4
date: 2013/07/18 21:17:28; author: amitdalal; state: Exp; lines: +1 -1
added -lpthread for compilation
—————————-
revision 1.3
date: 2013/07/15 21:55:17; author: amitdalal; state: Exp; lines: +4 -3
add unlink node
—————————-
revision 1.2
date: 2013/07/11 06:00:23; author: amitdalal; state: Exp; lines: +2 -2
make another node for reading
—————————-
revision 1.1
date: 2013/07/11 05:16:48; author: amitdalal; state: Exp;
Initial revision
=============================================================================

Posted in Character Driver, Uncategorized | Tagged prabjot | Leave a comment

E 30.01.30 : Kushal Chugh

Posted on July 22, 2013 by kushal.chugh

?
ARTICLE:

CHARACTER DRIVER.

Heard so much about Character Driver when i came to Emblogic and now I am working on Character Driver on Linux from last couple of weeks.

Driver – As per my knowledge a Driver is basically a communication medium b/w the application layer and the hardware.
Device Drivers is classified into three basic types: (i) Character driver, (ii) Block driver and (iii)Network driver.

A Character device is one that can be accessed as a stream of bytes i.e. character by character and it sends the data byte by byte to the kernel buffer and user buffer when application give call of write and read respectively.

We use the driver as LKM(Loadable Kernel Module) as it is not essential to keep driver present in the kernel until system is power on. Each module is made up of object code that can be dynamically linked to the running kernel by the insmod program and can be unlinked by the rmmod program. Whenever we do insmod, the macro ‘module_init’ invokes our initialization routine and module is inserted to the kernel if it is valid. And when we do the rmmod, our module gets removed from the kernel through the macro ‘module_exit’. Our initialization routine registers the driver for the devices and obtains major no. from the registration call int register_chrdev_region(); or int alloc_chrdev_region()); which is defined in the library fs.h . After registering our device, we have to initialize all the resources that are going to be used in our device program. In module_exit, the exact opposite of initialization procedure is performed but in the reverse order. All the resources allocated to the driver will have to be freed . After our module gets inserted successfully onto the kernel,it can be seen in /proc/modules file.

We develop Charater Driver because it is most suitable for simple Hardware devices.
For implementing my character driver, we have used SCULL (Simple Character Utility for Loading Localities) because of its advantage that it does not depend upon hardwre. Scull is just some memory which is allocated from the kernel. We have defined the behaviour of the system calls for the device. We have used cdev_init and cdev_add functions to initialize the struct cdev. Struct cdev is the actual representation of the device.
Next step is to map the system calls with the routines written in my character driver. In our open routine,we are checking the mode and depending on that mode, we are performing some specific tasks . In the open routine we mappthe scull to the device by using the macro ‘container_of’. The return value of container_of will be starting address of mapped memory that we will use to read and write on device and we store this address in the private_data of the struct file structure defined in fs.h library. The difference between the kmalloc and container_of macro is that using kmalloc, the memory is allocated in the RAM but container_of macro maps the maps the scull into the device.

Write Data & Read Data.
In our write routine we write the data from application to the device via scull quantum by using copy_from_user() function. Write routine also checks for the offset value (file position) where the application wants to write.
In read routine we read the data from the device via scull quantum by using copy_to_user() function. Read routine also checks for the offset value from where application wants to read.
We have also implemented lseek routine that sets the offset value as provided by the application in lseek system call.

Now the time has come to test the driver.
(i) Compile and insert our module in running kernel dynamically. This is done byinsmod on shell here lkm is my name of c file of driver.Compilation of the file should be by Makefile.

(ii)To make communication possible between application application and device driver,we require node in (VFS).
Node is created by the command “mknod node_name c major no. minor no.”, where c specifies that it is for character driver.

(iii)After testing we should have to remove the module from kernel with command “rmmod” like rmmod lkm to free the allocated major number.

Character driver though while working was not an easy task to accomplish but with guidance of Sir and fellow friends it was a great experience.

Posted in Character Driver, Device Drivers | Tagged Mr.Pravjot Singh | Leave a comment

RANA BRIJENDRA SINGH

Posted on July 22, 2013 by ranabrijendra12

SUBMITTED TO: Mr. PRAVJOT SINGH LINUX DEVICE DRIVERS

v ARTICLE ON CHARACTER DRIVER:

THIS ARTICLE IS ALL ABOUT TO THE CONCEPTS THAT I HAVE LEARNED AND MAINLY CONCERNED TO THE WORK WHATEVER I HAVE PERFORMED IN THE PROJECT REGARDING ASSIGNMENT IN ORDER TO SUCCESSFUL COMPLETION OF TRAINING.

v INTRODUCTION OF CHARACTER DRIVER:

AS THE NAME SUGGESTS ,THE DEVICE -DRIVER PROVIDES THE MECHANISM TO DRIVE THE HARDWARE(DEVICE) ACCORDING TO THE APPLICTION.THE TYPE & CATEGORY OF THE DRIVER IS DEPENDENT ON THE TYPE & REQUIREMENT OF APPLICATION WHICH WEAREUSING. WHICH MEANS TOSAYTHAT TO ACCESS THE PENDRIVE WE NEED USB DRIVER ,FOR BTLUETOOTH WE WE NEED BT DRIVER & FOR MEDIA PLAYER WE NEED A SEPRATE ONE. DIFFERENT TYPES OF APPLICATION REQUIRES DIFFERENT TYPE OF DRIVERS.

CHARACTER DRIVER WORKS FOR CHARACTER DEVICES WHICH CAN BE ACCESSED AS STREAM OF BYTES. SUCH DRIVER USUALLY IMPLEMENTS OPEN, WRITE, READ & CLOSE SYSTEM CALLS.

I think One of the good features of Linux is the ability to extend at runtime the set of features offered by the kernel. This means that you can add modules to the kernel (and remove modules as well) while the system is up and running. The need of using device drivers is to increase the functionality of kernel . Each piece of code that can be added to the kernel at runtime is called a module. Each module is made up of piece of codes that can be dynamically linked to the running kernel by the insmod program and can be unlinked by the rmmod program.

Currently I am working on character driver & its practical implementation. In this article I am going to discuss what i know about character driver briefly.

Now as I have to make my driver capable of directly handshake-able with the kernel so it was essential to work in kernel space instead of user space ,so i have to use the kernel libraries(like kernel.h, init.h ,fs.h etc..) instead of glibc libraries(like stdio.h,stdlib.h,fcntl.h etc…).

v HOW TO IMPLEMENT?

I AM GOING TO DESCRIBE THE BASIC STEPS WHICH I HAVE FOLLOWED WHILE IMPLEMENTING CHARACTER DRIVER:

– I started to write the program using two predefined macros named as module_init (entry_function) and module_exit(exit_function) as entrance point as main() in user space and exit point respectively.In which I have written my own start & end function. So after executing module_init execution will start from my function where I have to specify the major number and name of our driver, capacity to handle maximum number of device at a time and maximum memory of the driver. The major number identifies the driver associated with the device. I am firstly allocating major number to my driver which is basically a highest possible integer value between 0 to 255 by which our driver will be known in the kernel like other device drivers as stored in /proc/devices file .We can select major number for our driver from previously mentioned path but generally we privilege kernel to select major number because kernel will allocate it dynamically .This can be done with the register_chrdev_region() function call defined in fs.h which is in kernel library .In current scenario register_allok_chardev_region is in trend to do the errlier mentioned task .This will give the result of 32 bit(12 + 20 bit) at the address as give in first argument of call. After that I have used the first 12 bit i.e major number but i specify my own minor number generally 0 to upward in MKDEV() macro defined in kdev_t.h. After that I have allocated memory to sculldev structure(user defined structure that contain all information of the driver)) & separately initialized all its members as sculldev initialization function .Now used the cdev_init() and cdev_add() to initialize and add the cdev structure for our device which will contains the device specifications. Now I have written separate functions for each ( to create scullQsets structures, create q-sets structures, create quantums)& called these functions from write & read functions of driver modules to perform the desired operations in device.

In order to perform various operations like open, write, read, lseek and close file I have written an application in user space & mapped it similar kind if file operations (open, write read, llseek, release)that is in my driver program .So i have mapped these system calls in struct file_operations structure with my respective open,write,read,lseek and close functions according to prototype defined in <fs.h> kernel header file that will now handles the application calls instead of drivers of the OS.

But Before doing anything we have to map our allocated memory with the device memory this is done in the open function of driver with

container_of(ptr, type, member) in which first argument is pointer to i_cdev member of struct inode,2nd argument is user defined structure which contains pointer to struct cdev and third argument is pointer to struct cdev.Actually struct cdev is actual representation of the device. Now return of container_of will be starting address of mapped memory that we will use to read and write on device and i store this address in the private_data of the struct file structure defined in fs.h library.

After doing this now i have made my read, write and lseek function compatible with the almost all type of requests from application.In this write function will store the written data in own quantums when write request comes and give back that data according to the read request of application.I have also handled the single multithreaded application.

Now to test this driver we have to compile and insert our module in running kernel dynamically. This is done with command insmod ./modules/program name(without .c).ko & Compilation of the file should be by Makefile. After completion of work (successful insertion & execution of task) we have to remove our module this is done by command rmmod program name(without .c).

If every step is correct & written in proper manner then program will run & it will give desired result otherwise kernel will be crashed.

REMARKS: THERE MAY BE POSSIBILITY OF ERROR IN SYNTEX, SENTENCES,ARGUMENTS (& SOME-WHAT IN CONCEPTS ALSO ). SO ANY COMMENT, CORRECTION, SUGGESTION IS CORDIONLY INVITED.

REGARD’S

RANA BRIJENDRA SINGH

Posted in Uncategorized | Tagged Mr.Pravjot Singh | Leave a comment

CHARACTER DEVICE DRIVER(ARTICLE)

Posted on July 22, 2013 by amit.dalal

ARTICLE
ON
CHARACTER DRIVER

I have been working on character device driver since last two to three weeks and here I am
giving you the concept and idea I am using in character driver till now.

Let us start with the basic idea about character driver before moving on what is happening in architecture which help me to create my device driver.
DEVICE DRIVER -> These are loadable kernel modules that can be inserted in kernel at the run time and they provide a well defined interface for hardware to respond to a specific application code that want to communicate with the hardware . user at user level gives some specific code through application and the role of these device driver is to make these command work for hardware.

CHARACTER DRIVER -> Character driver is driver that access the device character by character i.e a stream of bytes as in files.

MODULE -> It is piece of code that is used for communication b/w hardware and software

Device driver concept divided into two basic part.
1. user level -> where your application reside
2. kernel level -> where your modules and drivers reside
now question arise how link is created b/w user level and kernel level.
NODE -> node created the link b/w user level and kernel level
USER SPACE(APPLICATION)
|

KERNEL SPACE(MODULES AND DRIVERS)

|
HARDWARE

There are few structures which were defind in kernel and user space through which we can defined functionality of our device driver
KERNEL DEFINED STRUCTURE :
1. STRUCT FILE
2. STRUCT Inode
3. Cdev
USER DEFINED STRUCTURE:
1. Struct Sculldev
2. Struct Scull_qset
3. Struct file operations

Scull -> 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 Scull_qset. 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. *scull_qset
2. Scull qset_size
3. data_size
4. quantum_size
5. device_size.
6. struct cdev.
struct Sculldev //user defined structure Sculldev
{
struct Scull_qset *scull_qset; //pointing to 1st quantum set(Scull_qset structure)
int quantum_size; //current quantum size
int qset_size; //current array size
int data_size; //amount of data stored here
int device_size;
int open_count;
struct cdev var_dev; //cdev structure defined in cdev header file
}*sculldev; //used for pointing Sculldev

Scull_qset is a structure which store data or information. it mainly has two member:
1. *next -> pointer to next scull_qset
2. **data -> double pointer to your data, means first it will point to an array of pointer known as qset , contains quantum where actually our data is kept.
struct Scull_qset
{
struct Scull_qset *next;
void **data;
};

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 call.
Some defined system call:
1. OPEN
2. CLOSE(RELEASE)
3. WRITE
4. READ
5. LLSEEK
struct file_operations fops=
{
open:scull_open,
read:scull_read,
write:scull_write,
llseek:scull_llseek,
release:scull_release

};

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:
1. i_cev ->which points to your struct cdev. pointer to file operations.
2.
Struct file -> Members are:
1. *f_pos :- which takes the account of the cursor in your file. pointer to file operations
2. *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.

Struct Cdev—> It mainly has three member:
1. owner :- which specifies about its owner name
2. pointer to file operation
3. dev which contains major and minor no.

void Sculldev_initialisation(void)
{
int a,lv;
for(lv=0;lv Major no. is a number which is given to each and every device driver we have in our machine
Minor no -> Minor no. is the number which represents your the device associated with that particular device driver.

majorno=MAJOR(dev); //extract major no.from device number
minorno=MINOR(dev); //extract minor no.from device number

This is all about the architecture now lets have look on the operations or working.

STEPS USED IN IMPLIMENTATION OF CHARACTER DRIVER

1. Insmod -> which will load our module, module is a source code which is loaded on demand.
insmod ./modules/amit.ko

2. Registration -> register our device driver and device so that DD will get a major number and device gets its own minor number.
ret=alloc_chrdev_region(&dev,minorno,nod,DRIVER_NAME); //when we are registering one device (for dynamic allocation)

3.Allocation -> Allocate space to Scull in machine memory.
sculldev=kmalloc(sizeof(struct Sculldev)*nod , GFP_KERNEL); //allocate memory to Sculldev

4.Initialize Scull –> cdev_init— create link between struct inode and struct cdev… define owner.. cdev_add make attribute of device available to our kernel.
void Sculldev_initialisation(void)
{
int a,lv;
for(lv=0;lv flash data if present in the memory space which is assigned to scull

7.Open -> define open system call.
int scull_open(struct inode *inodep, struct file *filep)
{

struct Sculldev* pdev;
printk(KERN_ALERT”BEGIN:open SUCCESSFULLY :%s\n”,__func__);

pdev=(struct Sculldev *)container_of(inodep->i_cdev, struct Sculldev, var_dev); // map the memeory allocated to Sculldev to VFS which is going to return pointer(A convenience macro that may be used to obtain a pointer to a structure from a pointer to some other structure contained within it.)

filep->private_data =pdev; //all information stored in pdev pointer conatining address

if((filep->f_flags && O_ACCMODE) == O_WRONLY)
{

printk(KERN_ALERT”FILE OPEN\n”);
scull_trim(pdev);
}

printk(KERN_ALERT”END:open close SUCCESSFULLY: %s\n”,__func__);
return 0;
}

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.
ssize_t scull_write(struct file *filep,const char __user *buff,size_t count, loff_t *f_pos)
{
struct Sculldev *pdev;
struct Scull_qset *qset;
int noq,nosqs,i,j,ret=0,loop=0; //noq=no.of quantum,nosqs=no. of scull_qset,
int nobpq,noctw,nocsw,flag=0,bpos=0; //nocsw=no. of character successfully write
noq=nosqs=nobpq=noctw=nocsw=0;
pdev=filep->private_data; //fetch the device

printk(KERN_ALERT”BEGIN:write open SUCCESSFULLY: %s\n”,__func__);
if(!pdev)
{
printk(“no private data”);
}

nosqs=count/(quantum_size*qset_size); //finding no. of scull_qset required
if(count % (quantum_size*qset_size))
nosqs++;
pdev->scull_qset=create_scull_qset(nosqs); //creating scull_qset(Sculldev *pdev pointing towards *scull_qset)
if(!pdev->scull_qset)
{
printk(“no scull_qset found\n”);
}
noq=count/quantum_size;
if(count%quantum_size)
noq++;

qset=pdev->scull_qset;
create_qset(qset,nosqs); //creating _qset
create_quantum(qset,noq); //creating _quantum
nobpq=quantum_size;
nocsw=0;
noctw=count;
int offset=filep->f_pos;
printk(KERN_ALERT”offset=%d\n”,(int)filep->f_pos); //data write in quantum

while(nosqs)
{
if(noq>quantum_size)
{
loop=quantum_size;
}
else
{
loop=noq;
}
if(flag==0)
{
if(offset>quantum_size)
{
j=offset/quantum_size;
bpos=offset%quantum_size;
nobpq=quantum_size-bpos;
}
else
{
j=0;
nobpq=quantum_size-offset;
bpos=offset;
}
flag=1;
}
else
{
j=0;
loop=noq;
bpos=0;
}
for(i=j;idata[i]+bpos,buff+nocsw,nobpq); //copy data from user space
printk(KERN_ALERT”quantum=%d->write=%s\n”,i,(char *)qset->data[i]+bpos); //data write in quantum
nocsw=nocsw+(nobpq-ret);
noctw=noctw-(nobpq-ret);
if(noctw>quantum_size)
{
nobpq=quantum_size;
}
else
{
nobpq=noctw;
}
printk(KERN_ALERT”no. of byte successfully write=%d\n”,nocsw);
printk(KERN_ALERT”no. of byte not write=%d\n”,ret);
bpos=0;
}
nosqs–;
qset=qset->next;
noq=noq-quantum_size;
}
printk(KERN_ALERT”no.of qset=%d\n”,loop);

printk(KERN_ALERT”END:write close SUCCESSFULLY : %s\n”,__func__);
return count-ret;
}

9. Read -> read whatever you have written to quantum.
ssize_t scull_read(struct file *filep,char __user *buff,size_t count, loff_t *f_pos)

ret=copy_to_user(buff+nocsr,qset->data[i]+bpos,nobpq); //copy data from user space
10. Release-> de-allocate all the space, unregister your device and DD, remove your module.
int scull_release(struct inode *inodep, struct file *filep)
{
printk(KERN_ALERT”BEGIN:OPEN SUCCESSFULLY release: %s\n”,__func__);
printk(KERN_ALERT”END:close SUCCESSFULLY release: %s\n”,__func__);
return 0;
}

For unregistering :

static void cleanup(void)
{
int lv;
printk(KERN_ALERT “BEGIN: %s\n”,__func__);
printk(KERN_ALERT”\ngood bye\n”);
for(lv=0;lv make
For making node -> mknod node c 249 0

TO remove the driver -> rmmod amit

HERE I AM GIVING YOU THE IMPLIMENTATION PROCEDURE TO CLEARIFY THE ALL STEP:-

Initialization of driver -> Mapping of system calls from application to the driver -> open call -> Mapping of memory on to the device (including trim function) -> Write call -> Read call -> Seek call ->use of multi threaded application.

We have used command “insmod” to call the initialization macro i.e. module_init() which will insert the driver into the list of modules & “rmmod” to call the cleanup macro i.e. module_exit() which will remove the driver from the list.

Driver starts with the registration using alloc_chrdev_region(). This registration (using alloc_chrdev_region()) is done so as to get the major number dynamically for the driver. Correspondingly a minor number is generated for the first device.
We can also use register_chrdev() to register the driver if we want to assign the user defined major number.

After registration we got a 32 bit number stored in “dev” which is of “dev_t” type. First 12 bits will give major number by using macro “MAJOR” & remaining 20 bits will give the minor number by using macro “MINOR”.

After getting the major & minor number, now its time to initialize the SCULL i.e. Simple character utility for loading localities. SCULL is a char driver that acts on the memory area as though it was a device. This SCULL is defined by a structure “Sculldev” contains blocks of memory called scullqsets which are also called as items and each item contains qsets which are nothing but array of pointers pointing to specific locations known as quantums. The scullqset or item can handle data maximum upto the data equal to product of qset_size and quantum size. Further each quantum can store maximum of bytes equal to quantum_size defined by the developer. We can calculate the number of scullqsets and number of quantums required for storing given number of bytes. One thing which is very important that these “items” or we can say that “scullqsets” should be linked like “link list” so as to store the data in quantums of different scullqsets.

After initializing the structure Sculldev, now we have to initialize the structure C_dev which will give the information of our device i.e. Owner of the device, Major & Minor numbers, operations that our device can perform etc. After this its time to map the system calls to the corresponding functions defined in the driver.

As the mapping is done so now from the application end we will call the open system call which will call our defined function in driver. In normal routine open call creates a stream and after handing over of the stream this call terminates. For our driver we have written our own routines. In our open function we have used a macro “container_of” to map the memory allocated for scull from RAM to the device & along with the link of “Structure inode” with “Structure C_dev & SCULL. This mapping will return the starting address of the SCULL which we will store into the “private data” of the “Structure file”. When ever & where ever if we want to access the sculldev we will fetch the private data. After sending the address of Sculldev we will call the trim function.

If we want to write on to the device, we have to check whether the device is having something onto its memory or not. If we found anything in quantums, we first trim the data nothing but flushing out the previously written bytes.

After trimming we will call write from the application. This write system call will call the write function which we have in our driver as we have already mapped all the operations to be performed by the applications in “Structure file_operations”. Writing here means getting the data from the user buffer & writing it on the quantums present in the SCULL i.e. Memory of device. In the starting of write function we will fetch the private data so as to get the address of SCULL. For writing we will use “Copy_from_user()”. Before writing we will calculate the number of items (scullqsets) to be created along with the number of quantums. Now we want to read what we have written earlier in the quantums. For this we will call the read function. This means reading the data from the quantums & passing it to the user buffer which we will receive in our application. For this we will use “Copy_to_user()”.

Posted in Uncategorized | Tagged prabjot | Leave a comment

Article – Character Driver

Posted on July 21, 2013 by Rahul Attreja

With the help of this article I am going to brief the basics of character driver & the work done by me till date.
First of all few questions arises in our mind that what is a driver & what is the need of driver in OS?. In general, driver is used to run or drive something. Here we are using driver(set of codes) to setup communication between the Hardware Device and the Operating System, so that our OS can drive nothing but access the device with the help of the “Device Driver”.
Device Drivers are also described as Loadable Kernel Modules (LKM), as these modules are loaded when ever & where ever used. This concept of using drivers increases the run-time efficiency of the Kernel.
We are right now working on the project i.e. “Development of one of the driver named as Character Driver “.
Character Driver operates on the basis of transferring the data character by character. In our project we are dealing with one application running on the user space & our Device Driver running on Kernel space. Till date we are working on creation of Multi Threaded Application in our Char Driver coding which consists of follow steps –
Initialization of driver -> Mapping of system calls from application to the driver -> open call -> Mapping of memory on to the device (including trim function) -> Write call -> Read call -> Seek call ->use of multi threaded application.
We have used command “insmod” to call the initialization macro i.e. module_init() which will insert the driver into the list of modules & “rmmod” to call the cleanup macro i.e. module_exit() which will remove the driver from the list. Driver starts with the registration using alloc_chrdev_region(). This registration (using alloc_chrdev_region()) is done so as to get the major number dynamically for the driver. Correspondingly a minor number is generated for the first device. We can also use register_chrdev() to register the driver if we want to assign the user defined major number.
After registration we got a 32 bit number stored in “dev” which is of “dev_t” type. First 12 bits will give major number by using macro “MAJOR” & remaining 20 bits will give the minor number by using macro “MINOR”. After getting the major & minor number, now its time to initialize the SCULL i.e. Simple character utility for loading localities. SCULL is a char driver that acts on the memory area as though it was a device. This SCULL is defined by a structure “Sculldev” contains blocks of memory called scullqsets which are also called as items and each item contains qsets which are nothing but array of pointers pointing to specific locations known as quantums. The scullqset or item can handle data maximum upto the data equal to product of qset_size and quantum size. Further each quantum can store maximum of bytes equal to quantum_size defined by the developer. We can calculate the number of scullqsets and number of quantums required for storing given number of bytes. One thing which is very important that these “items” or we can say that “scullqsets” should be linked like “link list” so as to store the data in quantums of different scullqsets.
After initializing the structure Sculldev, now we have to initialize the structure C_dev which will give the information of our device i.e. Owner of the device, Major & Minor numbers, operations that our device can perform etc. After this its time to map the system calls to the corresponding functions defined in the driver. As the mapping is done so now from the application end we will call the open system call which will call our defined function in driver. In normal routine open call creates a stream and after handing over of the stream this call terminates. For our driver we have written our own routines. In our open function we have used a macro “container_of” to map the memory allocated for scull from RAM to the device & along with the link of “Structure inode” with “Structure C_dev & SCULL. This mapping will return the starting address of the SCULL which we will store into the “private data” of the “Structure file”. When ever & where ever if we want to access the sculldev we will fetch the private data. After sending the address of Sculldev we will call the trim function. If we want to write on to the device, we have to check whether the device is having something onto its memory or not. If we found anything in quantums, we first trim the data nothing but flushing out the previously written bytes.
After trimming we will call write from the application. This write system call will call the write function which we have in our driver as we have already mapped all the operations to be performed by the applications in “Structure file_operations”. Writing here means getting the data from the user buffer & writing it on the quantums present in the SCULL i.e. Memory of device. In the starting of write function we will fetch the private data so as to get the address of SCULL. For writing we will use “Copy_from_user()”. Before writing we will calculate the number of items (scullqsets) to be created along with the number of quantums. Now we want to read what we have written earlier in the quantums. For this we will call the read function. This means reading the data from the quantums & passing it to the user buffer which we will receive in our application. For this we will use “Copy_to_user()”.
We have also done with seek function. Seeking means changing the position where we want to read or write. After seeking Multi Threaded Function is also created. Testing of is new threaded application is done & its working fine.
In linux everything is a file, whenever you connect a device it is treated as a file and an inode is created for that file. The communication between application and kernel is carried out using “node(named pipe)” created using command “mknod”. The application cannot access beyond this node. This node is the only medium from which the application will interact with the device driver.

This is all about what I have done till date in character driver coding.

Thanks
Rahul Attreja

Posted in Uncategorized | Leave a comment

prince singla E -30.01.30

Posted on July 21, 2013 by prince.singla

Device Drivers can be classified into three basic types:
1.Character driver
2.Block driver
3.Network driver.
A character device is one that can be accessed as a stream of bytes i.e. character by character. And code needed make communication possible b/w a character device and application is character driver.
Now lets explain the basic arch :-
memory are divided into two parts kernel space and user space .all the application in user space and all device driver in kernel space .the only way to interface between user space and kernel space through node.node will create by mknod. module_init and module_exit(MACRO)use to add and remove driver.module_init insert driver to memory(RAM) using lsmod.
module_init remove driver to memory using (rmmod) .if our driver is insert than we register driver using alloc_chardev_region().alloc_chrdev_region register driver ,creat the major(type dev_t) and they also register the driver for n number of devices.they will give address 32bits firts 12 bits are major number and left 20 bits are minor number.if we insert driver than they give highest avalible major number .the range of major number is (0 to 255). & give lowest avalible major no (range 0 to 255).one advantage of alloc_chrdev_region that register the driver n number of device .after register driver than kmalloc to sculldev.kmalloc give physical space(address) on memory(ram).
scull:-
scull is basically a linklist,every struct we can say node and they are connected to each other thats way we can say linklist ,the first node name as sculldev,struct sculldev first member struct scullqset and many more like private data,wcount,quantum_size,qset_size,device_size,c_dev,scull second node that is scullqset (member of sculldev).in scullqset first member is struct scullQset *next and second member is void **data,double pointer data is basically
pointout memory(that store information(double pointer data that is first pointout qset and that qset pointout quantum
that quantum store information(the size of quantum is 8 bits)).
In application we perform some task like open,write,read,close.in application firstly we want to open a node.than we using open system call(sys/open).in open system call we define two arr(string(file name),mode(permission)),that system call are define in glibe ,they open the node and return highest avalible fd.
container_of:-
In container_of(ptr,type,member) in which first argument is pointer to i_cdev member of struct inode,2nd argument is user defined structure which contains pointer to struct cdev and third argument is pointer to struct cdev.Actually struct cdev is actual representation of the device.Now return of container_of will be starting address of mapped memory(sculldev).
now node open application full access on node ,application any opertion perform like read ,write,close .but in my application first i write than lseek than again write after write read data.application write data driver will start write on memory(with the help of copy_from_user).first they check the size of data.than they check how many scullqset,qset and quantum needed and they create that.after this they perform read task,that is very similiar write opertion(read opertion using with the help of copy_to_user).after read opertion done call scull_trim().that are free the memory.to free the memory using kfree.
application:
now write the multithread one application.in application perform some task open,read,write,close on different thread.now to test this firstly compile char driver .after this module_init insert using lsmod.than execute application.working fine.after finished application than remove driver to use rmmod.

Posted in Character Driver | Tagged Mr.Pravjot Singh | Leave a comment

device driver

Posted on July 21, 2013 by prateek

Gud day sir,
Device driver,the name,the project,which we all were happy to start with because of easy in looking the functionality but same with compexity internally.on the very first day of the project,got a brief introduction on the topic. the second day was the main because on that day the internal structure of the device driver came into picture and unfortunately i was late and didnot attend the lecture .but thanks to Hemant ,who briefed me all so well that i felt it was taught by sir himself .
REGISTRATION AND UNREGISTRATION
In the beginning of programming ,we did the registration of our driver by ALLOC_CHRDEV_REGION function and got the MAJOR NO. for our driver.MAJOR NO. is a no. specifically allocated to a specific driver dynamically(if using ALLOC_CHRDEV REGION) and if we want to allocate some major no. that is free in the kernel then we can use the function REGISTER_CHRDEV_REGION.the no. got after registration is stored in dev function which is in struct inode which is the internal structure created by kernel regarding driver.registration is done in ENTRY FUNCTION which is the first to open.
then after registration we allocate memory for the user defined structure(sculldev) i.e the predefined copy for the device or application that we will open by this driver,having the same memory as that of opened application for read and write operation by kmalloc(defined in slab.h).
then we initialized the cdev structure which is defined in cdev.h by initialized all its arguments.the cdev structure is the structure which is used to get interface of our driver with the kernel.after intialization we add the cdev in kernel by cdev_add function.
we get a minor no. when we open a file or application through our driver (least possible value starting from 0).
this makes our driver inserted into kernel.
now comes the unregistration.this is done in EXIT function everything we did in entry function will be reversed here.deallocation of sculldev by kfree function,cdev_del and unregister_chrdev_region.

OPEN FUNCTION
the prototype of this function is defined in struct file_op in fs.h.we did 3 functions in this
1. container_of()–we take three arguments in this .first one is the pointer to a field (2nd argument) of type (3rd argument)container field within the structure of type container type and returns a pointer to the contained structure.
2. Storage of the pointer in the private_data in struct file.
3. Trimming if opened in write operations.
Release function
this is just the reverse of open .as such we did nothing to release but we are supposed to do opposite what we did in open function.
Write function
then comes the write function. That is to write in the sculldev ,user defined copy of the application,from the application openned. Writing all done by the function called copy_from_user.
But before this we did the allocation part that is making of scullqsets ,having the qsets having the pointers to the quantoms. The structure is just like the linked list . The sculls have the pointer points to the next scull and so on.
copy_from_user() having three arguments destination,source and the bytes to write in.source is the user buffer and the destination is the quantums.
Read function
whatever we write in quantums is time to write in the user buffer. The used function is copy_to_user. The function is same as copy_from_user.

lseek function

the function to implement is to change the file_position ,means to write and read in the quantums from the desired position by the application user. it is done by llseek function having three arguments,storing the value in struct file’s f_pos which is further used to change the position to write.

sir,i have done till the write lseek part but there is a problem in writing above 64 bytes and offset value for seeking is above 64 bytes. the writing is not done after 204 bytes including offset but after that writing error occurred instead of having left quantums available. still working on it . sorry if i am not up to date .i will recover soon.

thanks

prateek

Posted in Uncategorized | Leave a comment

DEVICE DRIVER

Posted on July 21, 2013 by ritesh.agrawal

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.

now our first device driver is partially ready. lot more things to do. stay tuned for more updates.

Thanks and Regards.

Posted in Uncategorized | Leave a comment

Character Driver Article

Posted on July 21, 2013 by ashish.verma

Article On Character Driver
This Article is based on how I implemented character driver till now. First of all we have to know actually what a driver Is. Let take a example in real world we have a man who can drive a bike but can’t run car so we need a driver who can run a car .in the similar way there are some specific hardware devices which can’t be run on simple program for that we need a special program. This program load in the kernel as a part of our operating system ,run and remove when it need is ended. They are used to
1.To allow interaction with hardware devices
2.Black boxes to hide details of hardware devices
3.Use standardized calls
4.Map standard calls to device-specific operations

So device drivers are that loadable kernel modules which insert in kernel ,work as part of kernel and removes as the need is ended.
Now there are Basically three types of drivers:
1.Character Driver
2.Block Driver
3.Network Driver
Character Driver:- First of all in driver we have to know that we are legally hack the kernel so we cant user level commands here for example we can’t use printf ,we use printk instead of that.
In kernel level there are two main functions which are module_init (arg) and Module_exit (arg).Here arguments is our start and exit functions. This is the two main micros of a driver. That mean a driver perform Module_init at starting and Module_exit on exit.
module_init (fn name):In module _init we register our driver by using
alloc_chrdev_region(&dev, minorno, nod, DRIVER_NAME);

in this dev id dev_t type and minor no is device no and nod Is number of devices .
now we get a a combination of major and minor no in dev which is of 32 byte in which 20 byte is of minor no and 12 byte is for major no. we can get our major no. by using micros major(dev) and minor(dev) this will give major and minor no.
We make our user defined function sculldev which have all the information about the device and allocate memory for it using Kmalloc. Which return a pointer which points to it starting address.
Now initialize our C_dev which is points to struct cdev and fops.
cdev_init (&sculldev->c_dev, &fop);
we can inform the kernel about this c dev structure using the cdev_add call.
int cdev_add(struct sculldev ->c_dev, dev_t dev, unsigned int count);
this is our start function. Now we proceeed to exit one.
In exit function we do nothing but to unregister device and free the memory allocatd to sculldev.
Now we go to our header file and define our sculldev structure and assign its members that are our quantum_size ,qset size,device size.and struct cdev type c_dev and struct scullaset *scullqs.et which points to our structure ScullQset which contains two things which are first our next pointer which points to out next scullqset structure and second is data pointer which contains qset which actually an array of pointer.It contains starting address of quantums.Ultimately our data is going to store in the quantums.
The whole structure of ScullQset is known as Item.We can relate it as our linked list which has next pointer and an info part.
This is our scullqset structure.

struct ScullQset
{
struct ScullQset *next;
void **data;
};
.
Now as we know that every device has its own set of open,close etc fn. So we have to map it using a structure names file_operations.
const struct file_operations fop=
{
open:scull_open,
write:scull_write,
read:scull_read,
release:scull_release
};

Here we map open call by scull_open means whenever a open call is make the command goes to scull open and perform scull_open.Simiarly we can map any no. of user level command.
Now we are defining prototypes of mapped command which are given in fs.h libraray which can accessible in kernel file.
int scull_open(struct inode *, struct file * );
int scull_release(struct inode *, struct file * );
ssize_t scull_read (struct file *, char __user *, size_t, loff_t *);
ssize_t scull_write(struct file *, const char __user *, size_t, loff_t *);

Now after that I write our open function in which I use Container_of which is used to map scull memory on device.
I preserve starting point pointer i.e sculldev in filep->private data.
Now In read fn . I get data from application and perform some calculation which give me idea on how many no. of quantum’s I needed to write this data .After that I write the data in Quantums by using the micro copy_from_user(destination,source,len)
Now I mapped the read function also so I read this data and show it in application by micro copy_to_user (destination, source, len)
Now I make a simple application and test it .I pass the data by using file descriptors.
I make a node which connect device driver to application.
I connect the application with device driver code by writing a command in script as
./ appl node.
Loadable Moduler kernel can be inserted and removed from the running kernel(using kernel utilities insmod and rmmod respectively);
Successfully worked till this. Working on lseek now.

Posted in Uncategorized | Tagged pravjot sir | Leave a comment

30.1.30 : Monika

Posted on July 20, 2013 by monika.chahal

Character Device Driver

I’ve been working on character device driver since last few days and here i can share what all i have learnt till now.

Device drivers are the Loadable Kerenl Modules(LKMs)that can be inserted in the kernel at run time. They act as black boxes and provide a well defined interface for hardware to respond to a specific application code that want to communicate with the hardware. User just gives some specific code through application and to make these commands work in the hardware is the role of device driver.

Character device is the device that can be accessed as character by character, i.e., as stream of bytes as in files.

And characeter driver is the one that handles character devices.

The basic operations that a character driver atleast provides are open, write, read, release.

Implementation:

The very first operation to perform is inserting the driver into kernel when we want to access the device and when our work is done then to remove the module from kernel space. These two operations can be performed using module_init(init_func_name) and module_exit(exit_func_name).The initialisation function and exit function are written separately and passed to these macros.

The next step is to register our driver for any no. of devices using alloc_chrdev_region(). A single driver can handle any no. of devices and therefore to recognise driver and devices major numbers and minor numbers are used.Major no. are used by kernel to recognise the driver and minor no. are used by driver to recognise devices. Major no. and minor no. as a combination are stored in dev_t datatype that is a 32-bit field with 12 bits for major and rest 20 for minor numbers.Using MAJOR() and MINOR() macros we can take out major and minor numbers from dev_t while if we have them separately we can dev_t using MKDEV().

When inserting the module durimg run time we usually don’t know the correct major number that is free so we dynamically allocate the major number and minor number and the return type of alloc_chrdev_region() is the first device number for ‘n’ number of devices.In exit function we also have to unregister our module using unregister_chrdev_region() by providing the correct device no. and the no. of devices we want to unregister.

As we are working at kernel level so the library functions and header files that were available at user level will not work here. The header files are to be included from kernel directory. Similarly, malloc() function’s work here is done by kmalloc() function.

The most important structure here is SCULL(simple characetr utility for loading localities). Scull is a character driver that acts on a memory as though it were a device. The entry point to scull is pointer to struct sculldev and sculldev is allocated memory using kmalloc() for nod no. of devices. Struct sculldev has a field struct cdev which is the kernel internal representation of the device and we also have to initilaise this cdev field while setting up the scull.The cdev_init() initialises the cdev, cdev_add() adds the device to the kernel device drivers table and and in exit function we can unregister cdev using cedv_del().There are other fields as well in struct sculldev which are to initialised as their initial values. This also contains a pointer to struct scullqset which are same as linked list and consisits of node poinitg to next scullqset and data field which pints to qsetarray and qset contain pointers to quantums which actually store the data to writen to and read from device’s memory.

We can map our own operations to the standard function_calls such as open,etc. in struct f_ops which is predefined. Therefore we are supposed to write our own open, write ,read and release functions for our device.The application will communiceta with our device using a node which can be created using mknod macro. All communication will take place through this node between application and device driver and hence device.

Open function should just initialise the device and scull_trim function is used if the device is opened in write only mode.There is a macro ‘container_of’ that actually maps our scull onto the device’s memory by linking inode, cdev and sculldev structure. The resulting sculldev in private_data field of struct file so that the opened sculldev can be used durin write and read.

Write function will actually create scullqset, qsets and quantums depending on the size of data to write. We use a macro ‘copy_from_user()’ to write to quantums from the user buffer & this is a very important macro as it prevents application from directly peeping into the kernel and hence provides security.Similarly in read function we use ‘copy_to_user()’ to copy from quantums to the user buffer.

Release function just releases all the acquired parameters when the application closes the device.There is a funcion for lseek as well if the user wants to append something to previous data or user wants to read some selected data.

I’have learnt till here till now and hope that soon i’ll be able to complete my character driver!!

Posted in Character Driver, Device Drivers | Leave a comment

EmbLogic's Blog

Blog Members Area

Embedded Systems Trainings

Industrial Trainings

Android System Development

C with Linux

C++ with Linux

Linux Internals and System Programming

Linux Device Drivers

Embedded Applications with ARM

Embedded Systems using 8 bit Controllers

Blog Categories

Charecter Driver log file

CHARACTER DEVICE DRIVER

VARIABLES IN SHELL SCRIPT

Charecter Driver log_file

CHARACTER DRIVER

CHARACTER DEVICE DRIVER

E 30.01.30 : Kushal Chugh

RANA BRIJENDRA SINGH

CHARACTER DEVICE DRIVER(ARTICLE)

Article – Character Driver

prince singla E -30.01.30

device driver

DEVICE DRIVER

Character Driver Article

30.1.30 : Monika