B97 : Device Driver Development

sankalpnegi2310

Please post your queries, updates, useful info , work log etc.

sankalpnegi2310

Basic MAKEFILE that we will be using in our project :

INSTALL_DIR=modules
ifneq (${KERNELRELEASE},)
    obj-m :=lkm97.o

lkm97-objs := init.o clean.o

else
    KERNELDIR ?= /lib/modules/$(shell uname -r)/build
    PWD := $(shell pwd)
default:
    $(MAKE) -C $(KERNELDIR) M=$(PWD) modules
    @rm -rf ${INSTALL_DIR}
    @mkdir ${INSTALL_DIR}
    @mv -f *.o *.ko *.mod.c .*.cmd ${INSTALL_DIR}
clean:
    rm -rf ${INSTALL_DIR}
endif

# dont forget to "chmod +x Makefile"

vishwajeet.gaur1989

Guys if you do not find kernel logs on path /var/log/messages or /var/log/X.org.2.log kindly use command journalctl to display kernel logs on shell.

However you can also view the same logs in /var/log/messages but messages file won't appear to you until you install syslog-ng on your fedora 20+ OS. Post installation of syslog-ng you will be able to view kernel logs on path /var/log/messages.

Ubuntu and other linux distro users kindly check this as well and post the solution if above doesn't work for your OS.

adeshagarwal02

@vishwajeet.gaur1989
yum install syslog-ng not working in my pc

is there any other to get /var/log/messages

sankalpnegi2310

Basic system requirements for creating Device Drivers :
(For Fedora based systems)

A system capable of creating device drivers must atleast have the following 3 files in "/lib/modules/<kernel-version-with-arch>/build" :

Makefile
Kconfig
Modules.symvers

Else, we need to install 2 packages in order to get our build folder, which in this case would be unlinked beacause the kernel-headers are missing under "/usr/src/kernel/" :
kernel-devel : Development package for building kernel modules to match the kernel.
kernel-headers : Header files for the Linux kernel for use by glibc.

Command to install: (yum will also do!!)

dnf install kernel-devel kernel-headers

this mayalso be written for a specific kernel version as follows :
dnf install kernel-devel-4.11.3-202.fc25.x86_64 kernel-headers-4.11.3-202.fc25.x86_64

sankalpnegi2310

ISO C90 forbids mixed declarations and code error !!!

Reason :

The original version of standardized C language (ISO C90) forbids mixing declarations and code. ... In newer versions of C language (C99 and later) you can freely mix statements and declarations, until the C99 standard, all declarations had to come before any statements in a block.

Solution :

Just place all the declaration statements before any statements, and you will be fine.
eg. put all the declared variables before you write any statements inside the function that throws this warning/error.

adeshagarwal02

Installing the kernel (sources)

The Kernel tarball is distributed in both GNU zip and bzip2 format. Bzip2 is the default and preferred format because it generally compressed better than gzip.
The Linux kernel tarball in bzip2 format is named as linux-version.tar.bz2, where version is the version of particular kernel source
After downloading the source uncompromising and untarring it is simple.

If tarball is compressed with bzip2
Than run
$ tar xvjf linux-version.tar.bz2

If it is compressed with GNU zip
Than run
$ tar xvzf linux-version.tar.gz

sankalpnegi2310

Issue :"insmod: ERROR: could not insert module modules/stack_driver.ko: Unknown symbol in module"

when calling a dynamic module that has already been exported (EXPORT_SYMBOL) into the kernel space by some other module, we get this error when trying to insert (insmod) the calling module.
This is very confusing because, even if we have not exported the module in kernel space, the compiling of the calling function should not display "Unknown symbol" as the module has been properly declared and called.
If a module has been compiled properly it should only malfunction only during runtime, in case of any illegal execution, but having compiled, it shows issue with insertion. why??

Please post your views and solutions if any.

ashutomar07

Issue::- Could not able to remove module inserted into kernel registered driver using rmmod command entry is still shown in symbol table when we check with dmseg command?
I have have Exported the module successfully but not able to remove it.

ashutomar07

Issue::- Is it necessary to register and de-register a Module using
module_init &
module_exit functions by using
register_chardev_region() and unregister_chardev() in test MODULE also.
I have inserted a module in a registered character driver with using above procedure. But i have not register that module.
Exported by using ""EXPORT SYMBOL(mymodule)
In mymodule.c file given just two : printk statements for Begin and end of code.
Is this right way to do so?
why we have to register a module?
By registering it we will get another majorno from test file aslo?

ashutomar07

ALGORITHM FOR WORKING AT KERNEL LEVEL FOR WRITING DRIVERS AND INSERTING THEM IN TO KERNEL.
1. Register/Unregister ur device ::
For working at kernel level u have to use module_init and module_exit functions , they are predefined macros in kenel
---U have to register ur device by using
int alloc_chardev_region(dev_t*,first minor no,no of devices,device name); which is to be given inside init_module function.
----U have to unregister ur device to release resources which are being used by ur device inside kernel by using
unregister_chardev(dev_t devid,no of devices)
-----module can be inserted using ""insmod""" followed by ur file.ko
-----module can be removed form kernel space using ""rmmod"" followed by ur file.ko
2. Allocate memory for scull device
(i) Memory will be allocated inside kernel space
(ii)Concept of stack , heap segment and dynamic memory allocation is not valid while kernel level programming
(iii)memory could be allocated using----(Dev*)kmalloc(sizeof(dev*)*nod,GFP_KERNEL) ------include<linux/slab.h> should be included for allocating memory in kernel space---------------The size of memory should be equal to struct dev structure which is part of SCULL- Simple character utility for loading localities
3. Set memory to null using memset
4.Initialize Device::
(i) Initialize all the fields under cdev structure for each device
5.Get device status
(i)Insert all the default parameters according to the data sheet by using MODULE PARAMETERS
(ii)module_param is the macro used followed by arguments.
(iii)Use header file #include<linux/moduleparam.h>
ALL of the above is a brief overview for starting with CHARACTER DEVICE DRIVER DEVELOPEMENT

sankalpnegi2310

@ashutomar07

Some basic concepts and checkpoints:

make sure you have written the cleanup function properly (with a void static declaration), moreover check for module_exit() issues (that you are calling the rigth module) as this is what is run once the rmmod is given.
Make your EXPORT_SYMBOL(module) as global, declared before the __int function.
as asked, "dmesg" shows the kernel logs, which are present until the system is rebooted, hence they will stay.
Your module table entries shall be updated after insertion and removal, that can be checked with "lsmod".
Moreover, we may export the dynamic module into the kernel without registering the module with register_chrdev() or similar calls, as the only purpose is to export with EXPORT_SYMBOL().
But yes if you register then removal is a must.

For further queries, please post the ERROR code as well.

sankalpnegi2310

Hijacking system calls at the kernel : [THEORITICAL CONCEPT]

System calls that generate a file descriptor can be manipulated at the kernel level, so as to run user defined routines.
Any call from the application layer can be hacked by tweaking the kernel data structures.
The concept lies in understanding the "file_operations" kernel data structure that is invoked for system calls like read(), write(), etc.
We can define our own structure of file_operations type with predefined routines.
Then we need to hijack the call by creating a routine that has function pointer routines of "struct inode" type.
The invocation by a system call is mapped to the user defined open(), close() calls that are written in the user defined data structures.

We shall see a realtime practical application, where we shall hijack the open and close system calls at the kernel level.

sankalpnegi2310

Hijacking system calls at the kernel : [PRACTICAL APPLICATION]

As explained above, now lets see the practical aspect of hijacking a system call in and redirecting it to a function of our choice.
Whenever a system call like open() is given, the kernel data structure for the device (struct cdev) is consulted for the file_operations pointer, that stores the function pointer for the system call, for eg open() call function pointer in the generic file_operations structure is represented by:

int (*open) (struct inode *, struct file *);

As a function pointer is just a address, the trick is to change this to an address of our choice (our own open() call routine address)
In our program we make a user defined structure for device called "Dev" structure, that has a standard cdev structure variable c_dev, which will have a standard file_operations variable *ops, where we will be mapping our own file_operations structure pointer address (here called fops), like this:
cdev_init(&device[dev_count].c_dev, &fops);
device[dev_count].c_dev.ops = &fops;
We also need to make a node, that will be the interface in between the kernel and user space, that shall be appearing as a file from the application layer
mknod c <major number value> <minor number value>

Now when the application layer system call open() is executed, it connects to this node and this node links the call to our device representation structure c_dev, that has already been mapped to our own file_operations pointer variable fops.
c_dev.ops has the value of fops variable, that is it will now access the function defined in our file_operations pointer *ops, and not the generic file_operations pointer.
Hence open() system call will no longer run the system routines but our own.

adeshagarwal02

RCS file: clean.c,v
Working file: clean.c
head: 1.1
branch:
locks: strict
    root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
----------------------------
revision 1.1    locked by: root;
date: 2017/07/21 15:48:32; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: decleration.h,v
Working file: decleration.h
head: 1.2
branch:
locks: strict
    root: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 2;    selected revisions: 2
description:
----------------------------
revision 1.2    locked by: root;
date: 2017/07/21 15:52:20; author: root; state: Exp; lines: +2 -2
*** empty log message ***
----------------------------
revision 1.1
date: 2017/07/21 15:48:36; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: fops.h,v
Working file: fops.h
head: 1.4
branch:
locks: strict
    root: 1.4
access list:
symbolic names:
keyword substitution: kv
total revisions: 4;    selected revisions: 4
description:
----------------------------
revision 1.4    locked by: root;
date: 2017/07/21 15:53:27; author: root; state: Exp; lines: +1 -1
*** empty log message ***
----------------------------
revision 1.3
date: 2017/07/21 15:52:59; author: root; state: Exp; lines: +2 -2
*** empty log message ***
----------------------------
revision 1.2
date: 2017/07/21 15:52:22; author: root; state: Exp; lines: +1 -1
*** empty log message ***
----------------------------
revision 1.1
date: 2017/07/21 15:48:36; 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
total revisions: 2;    selected revisions: 2
description:
----------------------------
revision 1.2    locked by: root;
date: 2017/07/21 15:49:57; author: root; state: Exp; lines: +0 -1
*** empty log message ***
----------------------------
revision 1.1
date: 2017/07/21 15:48:37; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: init.c,v
Working file: init.c
head: 1.1
branch:
locks: strict
    root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
----------------------------
revision 1.1    locked by: root;
date: 2017/07/21 15:48:34; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: opendev.c,v
Working file: opendev.c
head: 1.1
branch:
locks: strict
    root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
----------------------------
revision 1.1    locked by: root;
date: 2017/07/21 15:48:34; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: releasedev.c,v
Working file: releasedev.c
head: 1.1
branch:
locks: strict
    root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
----------------------------
revision 1.1    locked by: root;
date: 2017/07/21 15:48:35; author: root; state: Exp;
Initial revision
=============================================================================

sankalpnegi2310

Writing our own system calls at the kernel : [THEORITICAL CONCEPT]

System calls written by us need to have all the features of the original system call that we wish to hijack at the kernel level.
So we need to imbibe the mechanism for each of the features
For eg. our routine for the system call write() will look like :

ssize_t writedev(struct file *file_ptr, const char __user *usr, size_t size, loff_t *offset)

here we need to create a mechanism for all possibilities that the original write() call would have handled
This will be done by working with the stream representation kernel data structure file, user buffer type __usr, size, offset.
We will be required to deal with SKULL device architecture, wherein we will be setting up the utility for required quantums, depending upon device specifications.

All this shall be explained with practical illustrations while making the project.

sankalpnegi2310

Allocating required memory to the skull_dev structure:

When user gives a write() call, we need to allocate enough memory so as to store the transmitted data from user space
So, first we need to create a device space function whose job is to allocate some memory for the kernel space.
Each device has some memory specifications, like register size, no of registers in a set, device size, data size.
The data is allocated in several ways:
first we need to find the number of items we need to create, each item can have a maximum size of register size*no of registers.
we loop in for the appropriate size kmallocing size into the start node and to the last possible node, simultaneously updating the pointer to point to next node of linked list.
Now we have all the items ready with space to work with skull_dev.

ashutomar07

STEPS TO ALLOCATE MEMORY IN KERNEL SPACE TO SCULL STRUCTURE

First we have to declare our Qset structure variables which are *next and **data double pointer
We have received data form write() call of application in our device file created by mknod
Now we have to OPEN our device file and Write into it through application
We receive data sended from application to our driver write routine , we fetch data and allocate memory in skull accordingly
Before allocating memory space we should have details about device such as device size,Register size , No of registers etc
we have to firstly do kmalloc for our complte structure which is called item of type 'Qset'
After that we have find our qset array required and noq(no of quantoms) req to store char data sended from application
Then we have to create our first node and store its adress for future use.
Allocate memory for array of pointers which stores address of each register , this array is pointed by double pointer **data which is defined in skull dev structure
Allocate memory for each register whose size is given by our device seize register
Remember to do memset ,fill all allocated memory with null after kmalloc

sankalpnegi2310

Allocating memory for Qset Linked list [Procedure]

We need to do a total of 3 types of allocations, one for each node of the Qset linked list, one for data array in each field, and last for allocating memory to each element of these arrays.
Total size of text is received by the our write() call that evaluates the size if its bigger than device size, else the same size continues in the program.
This is the total number of bytes sent by the write() system call, then we decide the number of items required.
Each item has 32 bytes of memory (8*4) (no of registers * size of each) as per our device conventions.
so we use kmalloc for each node of linked list.
next we use kmalloc in a loop until number of items, and for each item we allocate memory, for each data field we allocate an array of addresses, where addresses are char* type.
Now we need to calculate the number of quantums to be created and allocated, which are decided by dividing the total size in bytes by product of register size and no of registers.
Now we loop in until no of quantums , thus sequentially allocating and freeing memory for each quantum.

sankalpnegi2310

Trimming operation in devices [Deallocating the Qset Linkedlist]

We need to do trim the memory that was allocated previously to the Qset linked list
As it is a linked list so we will proceed from last elements to first.
we select the last item (node) and deallocate each quantum starting from last
after that we shall free the entire data array
next we will free the entire item
These 3 poerations are looped in till we get the start node of this linked list to point to NULL.
This way the entire memory is deallocated
We will be using kfree() instead of free()
We will be needing another Qset * that would be pointing to the second last item
We should put the freed memory pointer to NULL, in order to avoid any dangling pointer scenario

adeshagarwal02

RCS file: clean.c,v
Working file: clean.c
head: 1.1
branch:
locks: strict
   root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;   selected revisions: 1
description:
----------------------------
revision 1.1   locked by: root;
date: 2017/08/04 08:54:50; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: create_buff.c,v
Working file: create_buff.c
head: 1.1
branch:
locks: strict
   root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;   selected revisions: 1
description:
----------------------------
revision 1.1   locked by: root;
date: 2017/08/04 08:54:51; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: decleration.h,v
Working file: decleration.h
head: 1.1
branch:
locks: strict
   root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;   selected revisions: 1
description:
----------------------------
revision 1.1   locked by: root;
date: 2017/08/04 08:54:57; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: fops.h,v
Working file: fops.h
head: 1.1
branch:
locks: strict
   root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;   selected revisions: 1
description:
----------------------------
revision 1.1   locked by: root;
date: 2017/08/04 08:54:58; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: header.h,v
Working file: header.h
head: 1.1
branch:
locks: strict
   root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;   selected revisions: 1
description:
----------------------------
revision 1.1   locked by: root;
date: 2017/08/04 08:54:58; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: init.c,v
Working file: init.c
head: 1.1
branch:
locks: strict
   root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;   selected revisions: 1
description:
----------------------------
revision 1.1   locked by: root;
date: 2017/08/04 08:54:52; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: lseekDev.c,v
Working file: lseekDev.c
head: 1.1
branch:
locks: strict
   root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;   selected revisions: 1
description:
----------------------------
revision 1.1   locked by: root;
date: 2017/08/04 08:54:53; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: opendev.c,v
Working file: opendev.c
head: 1.1
branch:
locks: strict
   root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;   selected revisions: 1
description:
----------------------------
revision 1.1   locked by: root;
date: 2017/08/04 08:54:53; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: readfromDev.c,v
Working file: readfromDev.c
head: 1.1
branch:
locks: strict
   root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;   selected revisions: 1
description:
----------------------------
revision 1.1   locked by: root;
date: 2017/08/04 08:54:54; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: releasedev.c,v
Working file: releasedev.c
head: 1.1
branch:
locks: strict
   root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;   selected revisions: 1
description:
----------------------------
revision 1.1   locked by: root;
date: 2017/08/04 08:54:54; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: trimed.c,v
Working file: trimed.c
head: 1.1
branch:
locks: strict
   root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;   selected revisions: 1
description:
----------------------------
revision 1.1   locked by: root;
date: 2017/08/04 08:54:55; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: writetoDev.c,v
Working file: writetoDev.c
head: 1.1
branch:
locks: strict
   root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;   selected revisions: 1
description:
----------------------------
revision 1.1   locked by: root;
date: 2017/08/04 08:54:56; author: root; state: Exp;
Initial revision
=============================================================================

saurabh.hmr009

RCS file: clean.c,v
3 Working file: clean.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 ----------------------------
14 revision 1.1    locked by: root;
15 date: 2017/08/04 08:56:13; author: root; state: Exp;
16 Initial revision
17 =============================================================================
18
19 RCS file: create_buff.c,v
20 Working file: create_buff.c
21 head: 1.1
22 branch:
23 locks: strict
24         root: 1.1
25 access list:
26 symbolic names:
27 keyword substitution: kv
28 total revisions: 1;     selected revisions: 1
29 description:
30 ----------------------------
31 revision 1.1    locked by: root;
32 date: 2017/08/04 08:56:22; author: root; state: Exp;
33 Initial revision
34 =============================================================================
35
36 RCS file: declarations.h,v
Working file: declarations.h
38 head: 1.1
39 branch:
40 locks: strict
41         root: 1.1
42 access list:
43 symbolic names:
44 keyword substitution: kv
45 total revisions: 1;     selected revisions: 1
46 description:
47 ----------------------------
48 revision 1.1    locked by: root;
49 date: 2017/08/04 08:56:26; author: root; state: Exp;
50 Initial revision
51 =============================================================================
52
53 RCS file: fops.h,v
54 Working file: fops.h
55 head: 1.1
56 branch:
57 locks: strict
58         root: 1.1
59 access list:
60 symbolic names:
61 keyword substitution: kv
62 total revisions: 1;     selected revisions: 1
63 description:
64 ----------------------------
65 revision 1.1    locked by: root;
66 date: 2017/08/04 08:56:27; author: root; state: Exp;
67 Initial revision
68 =============================================================================
69
70 RCS file: header.h,v
71 Working file: header.h
Working file: header.h
72 head: 1.1
73 branch:
74 locks: strict
75         root: 1.1
76 access list:
77 symbolic names:
78 keyword substitution: kv
79 total revisions: 1;     selected revisions: 1
80 description:
81 ----------------------------
82 revision 1.1    locked by: root;
83 date: 2017/08/04 08:56:27; author: root; state: Exp;
84 Initial revision
85 =============================================================================
86
87 RCS file: init.c,v
88 Working file: init.c
89 head: 1.1
90 branch:
91 locks: strict
92         root: 1.1
93 access list:
94 symbolic names:
95 keyword substitution: kv
96 total revisions: 1;     selected revisions: 1
description:
98 ----------------------------
99 revision 1.1    locked by: root;
100 date: 2017/08/04 08:56:23; author: root; state: Exp;
101 Initial revision
102 =============================================================================
103
104 RCS file: opendev.c,v
105 Working file: opendev.c
106 head: 1.1
107 branch:
108 locks: strict
109         root: 1.1
110 access list:
111 symbolic names:
112 keyword substitution: kv
113 total revisions: 1;     selected revisions: 1
114 description:
115 ----------------------------
116 revision 1.1    locked by: root;
117 date: 2017/08/04 08:56:24; author: root; state: Exp;
118 Initial revision
119 =============================================================================
120
121 RCS file: readfromdevice.c,v
122 Working file: readfromdevice.c
123 head: 1.1
124 branch:
125 locks: strict
126         root: 1.1
127 access list:
128 symbolic names:
129 keyword substitution: kv
130 total revisions: 1;     selected revisions: 1
131 description:
132 ----------------------------
133 revision 1.1    locked by: root;
134 date: 2017/08/04 08:56:24; author: root; state: Exp;
135 Initial revision
136 =============================================================================
137
138 RCS file: releasedev.c,v
139 Working file: releasedev.c
140 head: 1.1
141 branch:
142 locks: strict
143         root: 1.1
144 access list:
145 symbolic names:
146 keyword substitution: kv
147 total revisions: 1;     selected revisions: 1
148 description:
149 ----------------------------
150 revision 1.1    locked by: root;
151 date: 2017/08/04 08:56:25; author: root; state: Exp;
152 Initial revision
153 =============================================================================
154
155 RCS file: trimdev.c,v
156 Working file: trimdev.c
157 head: 1.1
158 branch:
159 locks: strict
160         root: 1.1
161 access list:
162 symbolic names:
163 keyword substitution: kv
164 total revisions: 1;     selected revisions: 1
165 description:
166 ----------------------------
167 revision 1.1    locked by: root;
168 date: 2017/08/04 08:56:25; author: root; state: Exp;
169 Initial revision
170 =============================================================================
171
172 RCS file: writetodevice.c,v
173 Working file: writetodevice.c
174 head: 1.1
175 branch:
176 locks: strict
177         root: 1.1
178 access list:
179 symbolic names:
180 keyword substitution: kv
181 total revisions: 1;     selected revisions: 1
182 description:
183 ----------------------------
184 revision 1.1    locked by: root;
185 date: 2017/08/04 08:56:26; author: root; state: Exp;
186 Initial revision
187 =============================================================================

sankalpnegi2310

Reading operation in devices [Algorithm]

We need to read / copy data back to the user space
A new structure of struct file type is created in the kernel, the moment we give a open() call in O_RDONLY mode
Using the container_of macro once again we shall get acces to the kernel skull dev structure
This time we have the already written data to the Qset linked list, so this needs to be copied to the user spae using the copy_to_user macro
To do this we will access each quantum from the appropriate item and copy that data to the pointer pointing to the buffer in user space
We will then increment the pointer to the user space buffer with the value successfully written characters
Thus we can copy data to the user space

sankalpnegi2310

Destructive Reading operation in devices [Algorithm]

A lot of devices read the data but as the same time don't store the data
These devices have a destructive read operation imbibed within them
This can be done in our driver by deallocating memory for each quantum, data array and the item itself once it has been read
we can do this by freeing each quantum as we read through it.
Once all the required quantum in a data array have been read and freed, we will free the memory occupied by the data array
After this we shall free the memory occupied by the item, for which we will need to store its address in another temp variable
This procedure is repeated untill we free up all the quantums, arraya and items as well

sankalpnegi2310

Partial Reading issues : [Destructive reading operation]

while reading in destructive_read mode, we need to check for the altering size of variable that decides the number of characters to read
The variable changes, in order to prevent us from overflowing the requested size, which is not encountered when complete file is read till end
Trim_func() is malfunctioning due to previously freed partial memory from the destructive read mechanism
The reason is pretty straight forward, the trim func() frees memory from the last, and the read() frees the memory from the start as it reads, so, we encounter a "segfault" or "kernel paging request issue", when we call trim after having read partially
Currently the solution for the last issue is under formulation

sankalpnegi2310

Seeking in a device : using "f_pos" from "struct File"

We map the function pointers for our own lseek() in the file operations variable, in order to replace the system call by our own
We take user input for "offset" and "origin"
When our function is called, we have these two values as arguments, their we write routines for 3 cases: 1. SEEK_SET 2.SEEK_CUR 3.SEEK_END
SEEK_SET -> new position = offset
SEEK_CUR -> new position = Current + offset
SEEK_END -> new position = End - offset
We can always get the current position in the file by using the "f_pos" field in the "struct File " pointer, that is received via formal argument
This way we can get to any location within the file

sankalpnegi2310

Synchronization mechanism in Devices [SPINLOCK]

Spinlock is the locking unlocking mechanism is case of devices
It basically checks for the required bit to be in "unlocked" state and then moves forward setting the that bit
This will lock the spinlock for the others unless the the thread that aquired the spinlock releases the spinlock.
Spinlock has ownership associated with and only the owner can unlock the spinlock
If the thread fails to get the spinlock, its shall keep hitting in order to acquire the lock, till its acquired
Spinlock can be implemented as: void spin_lock() and void spin_unlock()
We also have the functionality to disable interrupts (software and hardware)
The interrupt status can be temporarily stored in the flags

saurabh.hmr009

Synchronisation in Device Drivers(Spinlock)

It is non interruptible,non preemptible and atomic synchronization mechanism.
Used in code which cannot sleep.
Used when you dont want to let your quantum go to the scheduler too.
These are better than semaphores.
Locking and unlocking are done on a particular bit. Lock means bit is 1, unlock means bit is 0.
If a thread fails to acquire spinlock then it keeps hitting the critical region interface until it acquire spinlock.
spin_lock and spin_unlock are used to implement spinlock.
the ownership is associated with the one who acquire spinlock.

saurabh.hmr009

Synchronization in Device Drivers(Semaphores)

Many processes run in the user space and can access the code in anyway. The kernel code is preemptible,means at any time kernel can lose processor.
Since many processes can access the driver at same time , it can give rise to race condition.Race condition always gives unexpected results.
Two options to remove race condition, first to make driver which doesn't have shared resources,means no concurrent access of driver, second is to use some synchronization mechanisms on driver.
Semaphores can be used as one of synchronization mechanism in device driver. Semaphore structure is defined in the <linux/semaphore.h> header file and is set up in driver like:

void sem_init(struct semaphore *sem,int value);

int value is the initial value by which semaphore is initialized ,which normally is 1.

In linux, P functions is called "down" function . Down function decrements the semaphore value.
the V funtion in linux is called "up' function which increments the semaphore value.
If a thread is not able to acquire the semaphore tthen ERESTARTSYS is returned from down function.
Upon seeing ERESTARTSYS, the kernel higher layers will restart the call or will return an error to the user.
If return is ERESTARTSYS then you must first undo any user-visible
changes that might have been made, so that the right thing happens
when the system call is retried.

saurabh.hmr009

Synchronization in device drivers(Read/Write semaphore)

Many threads would like to access only read and write sections of the driver.
R/w semaphores allow multiple readers to read the critical section concurrently, as long as nobody is trying to make any changes.
Doing so can optimize performance significantly.
The r/w semaphore is initialized as : void init_rwsem(struct rw_semaphore *sem); .
down_read( ) and up_read( ) function are used in the read section.
down_write( ) and up _write( ) functions are used in the write section.
An rwsem allows either one writer or an unlimited number of readers
to hold the semaphore. Writers get priority; as soon as a writer
tries to enter the critical section, no readers will be allowed in
until all writers have completed their work.
This implementation can
lead to reader starvation—where readers
are denied access for a long time—if you have a large number of
writers contending for the semaphore. For this reason, rwsems are
best used when write access is required only rarely, and writer
access is held for short periods of time.

sankalpnegi2310

I/O Control in devices [IOCTL]

Most drivers need—in addition to the ability to read and write the device—the ability to perform various types of hardware control via the device driver.
In user space, the ioctl system call has the following prototype:
int ioctl(int fd, unsigned long cmd, ...)
The ioctl command numbers should be unique across the system in order to prevent errors caused by issuing the right command to the wrong device.
address verification (without transferring data) is implemented by the function access_ok :
int access_ok(int type, const void *addr, unsigned long size);
Unlike most kernel functions, access_ok returns a boolean value: 1 for success (access is OK) and 0 for failure (access is not OK).
If it returns false, the driver should usually return -EFAULT to the caller.

sankalpnegi2310

Partial destructive read() along with a device_trim() function ??

Whenever we allocate memory to the skull device, a quantum is the most fundamental unit,i.e. a register, so during a destructive read() operation, how is it possible to manage partial read() within a quantum??
As a block of memory fetched from malloc() shall always be freed as a whole, so it is not possible to free or preserve partial memory
Calling a device trim() function after a partial destructive read would result in a segmentation fault in kernel, so we need to update the device pointer to point to the next item after having read and freed each item, explicitly, during a destructive read operation.

sankalpnegi2310

Variable arguments in ioctl(File*, unsigned int, ...) ??

The third argument of the ioctl call, is a '...' argument, which according to c standards represents variable arguments, but that is not the case in here
We cannot have a variable sort of concept in crucial applications like device drivers
The purpose this is that the we will not get get any compiler warning for wrong types, unlike C
The default type is char *p, but it may change according to command type

sankalpnegi2310

The /proc file system : process information pseudo file system

It is called pseudo file system as it doesn't exists on hard drive but RAM
It is mounted at /proc
It holds the entries to some kernel code, currently executing
Entries for each running PID are present in the /proc file system
It is mostly read only, and has 0 size files
This is so because these files do not contain any data in them instead the provide information on the run(dynamically) from the kernel, whenever called from user space
Each entry in the /proc file system basically has the information about that particular process
An entry in the proc file system by the name of "self" enables program to inquire about its own process
Target destination for this "self" entry will depend on the invoking process

sankalpnegi2310

The /proc file system : Call back function frequency

There are 2 basic conditions that manipulate a call back functions frequency
1.) *eof = 1 2.) return length
when 1 and 2 are fulfilled : call back is called 2 times
when 1 is fulfilled and 2 is not fulfilled : call back is called 3 times
when 1 is not fulfilled but 2 is fulfilled : call back is called 1 time
when 1 and 2 both are not fulfilled : call back is called 1 time

saurabh.hmr009

/proc file system

It is a pseudo file system , means this file system is virtual and remain on the ram. It is only implemented in the memory.
Every entry in the proc file is connceted to a call back function which generates the required contents and send it to the corresponding application.
the entries in the /proc system mostly are the PID of the current processes running in the system.
The contents in a proc file are basically the informations regarding to the process running.
The size of a proc file is mostly 0. But if you open that file then it will show the current running information regarding that process.

saurabh.hmr009

/proc file system

In kernel environment , we can create our own proc file. This basically depends upon the kernel levels also.
In kernels 3.10 and before we need to define read_proc and write_proc separately.
We use create_proc_read_entry and create_proc_write_entry to create /proc file in these kernels.
In kernel versions 3.10 and after , the both read_proc and write _proc can be defined in a single command and that is create_proc_entry.
The return type of create_proc_entry is a pointer to the directory entry structure that is struct proc_dir_entry.
This mechanism is the advance proc file system.

B97 : Device Driver Development

Howdy, Stranger!

Categories