WEBVTT 00:06.250 --> 00:08.320 So welcome back, guys. 00:08.380 --> 00:14.350 Until now, we have just written one single standalone API, which is used to send messages from userspace 00:14.350 --> 00:15.610 to kernel space. 00:15.940 --> 00:20.540 Now we are in a process to write full fledged userspace program. 00:20.620 --> 00:27.190 So before writing any code, let us discuss the design model or thread model of our user space program. 00:28.370 --> 00:30.680 We have already discussed about it briefly. 00:30.680 --> 00:36.920 Now let us discuss with the help of a flowchart so that it would be easier for us to implement our Userspace 00:36.920 --> 00:37.640 program. 00:38.090 --> 00:43.880 So you can see our userspace program will start with the execution from Main, and the next thing that 00:43.880 --> 00:46.760 we will going to do is to create a netlink socket. 00:47.740 --> 00:53.530 In order to create this netlink socket, we will going to use the same protocol number which we used 00:53.530 --> 00:56.750 while creating a netlink socket in the kernel space. 00:56.770 --> 01:03.570 So the reserved number that we have been using is 31 and after that we will going to bind the socket. 01:03.580 --> 01:07.030 So when we will be discussing the code, I will discuss that. 01:07.030 --> 01:12.700 How to bind the Netlink socket, What needs to be done in order to bind the netlink socket. 01:12.700 --> 01:15.070 And we bind against what? 01:15.550 --> 01:20.320 And then in the fourth step we will going to start a separate thread. 01:20.320 --> 01:22.180 And we have already discussed that. 01:22.180 --> 01:24.260 Why we will be starting a separate thread. 01:24.280 --> 01:31.360 We will start a separate thread so that our userspace program can independently receive messages from 01:31.360 --> 01:37.170 the kernel space, while the main thread can independently send message to the kernel space. 01:37.180 --> 01:39.480 So you can see that in the main thread. 01:39.490 --> 01:45.610 Finally we get entered into the main menu and we will add more and more options to this main menu as 01:45.610 --> 01:49.430 we add more features to our user space program. 01:50.650 --> 01:56.710 So the very first option is the grid kernel option, which will simply send a text message to a kernel 01:56.710 --> 02:00.370 space, more precisely saying to our Linux kernel module. 02:00.400 --> 02:05.320 So grid kernel API will eventually invoke the API which we have already written. 02:05.320 --> 02:07.350 Send netlink message to kernel. 02:07.360 --> 02:08.170 Right. 02:08.290 --> 02:14.470 And once the sending of the message is finished, we again come back and we again run this main menu 02:14.470 --> 02:15.160 again. 02:15.280 --> 02:19.180 So this main menu will run in an infinite loop. 02:19.180 --> 02:26.140 Right now, coming to the thread that we have launched from the main thread in our userspace application. 02:27.070 --> 02:33.340 The other thread will have a responsibility to actually receive the messages from the kernel space. 02:33.370 --> 02:34.060 Right. 02:34.060 --> 02:40.540 So the flowchart on the right hand side actually represents the code flow of the separate receiver thread. 02:40.960 --> 02:46.210 So you can see that writing a logic for the receiver thread is pretty much simple and easy. 02:46.240 --> 02:53.060 All we have to do is to call, receive message system call and this receive message system call is a 02:53.060 --> 02:54.500 blocking system call. 02:54.500 --> 03:02.030 It means that receiver thread will stay blocked on this receive message system call until it receives 03:02.030 --> 03:04.690 some data on this netlink socket. 03:04.700 --> 03:05.420 Right. 03:05.420 --> 03:07.650 So this is a blocking system call. 03:07.670 --> 03:13.250 I hope you have some background on socket programming and understand what are blocking or non-blocking 03:13.250 --> 03:14.310 system calls. 03:14.330 --> 03:20.360 And once our userspace program receives a message from the kernel space, our userspace program will 03:20.360 --> 03:26.480 get unblocked from this receive message system, call and resume its execution further. 03:26.480 --> 03:32.030 So we will process the message, what we have received from the kernel space and we again go back and 03:32.030 --> 03:34.560 then block on the receive message system call. 03:34.580 --> 03:40.130 So this portion of the code is also running in infinite loop, right? 03:42.410 --> 03:47.910 So overall picture is that that our user space application is a two threaded application. 03:47.930 --> 03:53.810 The first thread is a main thread itself and it has the responsibility to continuously send messages 03:53.810 --> 03:56.000 to the kernel space through main menu. 03:56.030 --> 03:56.600 Right. 03:56.600 --> 04:03.590 So main menu runs in an infinite loop and then we have our receiver thread which also runs in an infinite 04:03.590 --> 04:10.400 loop and it stay blocked on the received master system call until it receives a message from the kernel 04:10.400 --> 04:11.060 space. 04:11.090 --> 04:17.270 Once it receives a message, we will process the message and again we go back and block on the received 04:17.270 --> 04:18.480 message system call. 04:18.500 --> 04:21.360 So the thread model is fairly simple and easy. 04:21.380 --> 04:26.600 So now in the next lecture videos we will going to implement this flowchart step by step. 04:27.350 --> 04:33.950 I would like to encourage you to implement this flowchart by yourself and feel free to skip the lecture 04:33.950 --> 04:37.520 videos if you are able to implement this by yourself.