WEBVTT 00:05.710 --> 00:09.850 So guys, we will start our implementation from the main function. 00:09.850 --> 00:13.960 And note that I'm in the same file that is userspace dot C. 00:14.770 --> 00:20.140 So first we will going to implement how to send message to the kernel space through the main menu. 00:22.410 --> 00:27.810 So as we discussed in the flow chart, the very first thing that we will going to do is to create a 00:27.810 --> 00:29.040 net link socket. 00:29.130 --> 00:34.890 You can create a net link socket using an API, create netlink socket, right? 00:34.890 --> 00:39.570 And you have to pass the protocol number as an argument to this API. 00:39.570 --> 00:42.810 And in our case this value is 31. 00:42.930 --> 00:50.400 So this API just create a socket and returns a numeric integer which represents a socket file descriptor. 00:50.430 --> 00:58.200 If the socket file descriptor is minus one, it means that socket creation has failed and you can print 00:58.200 --> 01:03.210 the error code, which could tell you the reason for the failure of this socket creation. 01:05.070 --> 01:07.620 Then we need to take some couple of variables. 01:07.620 --> 01:10.470 For example, we need to take the source address. 01:10.500 --> 01:16.140 Now, in this communication between user space and kernel space, who is the source? 01:16.170 --> 01:19.590 The source is this user space program, right? 01:19.590 --> 01:26.530 So in the source address, we will have to specify the identity of this user space program and note 01:26.530 --> 01:31.510 the data structure of the source address is of the type sock address underscore URL. 01:31.630 --> 01:32.380 Right. 01:32.800 --> 01:37.750 So these are the type of socket addresses which are used for netlink sockets. 01:37.900 --> 01:44.080 We will see how to specify and what information to specify as a source address in this data structure 01:44.080 --> 01:44.920 shortly. 01:45.850 --> 01:52.060 And let and let take a netlink header pointer which we will be using later. 01:52.060 --> 01:55.420 And let us initialize the source address. 01:55.540 --> 01:59.540 Now let us see what fields we have to fill in the source address. 01:59.560 --> 02:03.460 The first field that we have to field is the Netlink family. 02:03.460 --> 02:10.650 In our case, the Netlink family is constant and it is this value that is af underscore netlink. 02:10.660 --> 02:16.350 And the second value which we need to specify, is the process id of this process. 02:16.360 --> 02:21.490 So process ID you can obtain from the standard API get PID right. 02:21.820 --> 02:28.180 So in the source address data structure, we only need to fill these two fields so you can see that 02:28.180 --> 02:35.950 get PID is a process ID which is unique, which is a unique identity of a process system wide. 02:36.910 --> 02:40.960 And now we have to bind this netlink socket. 02:42.250 --> 02:45.220 So you can see the bind system call takes three arguments. 02:45.320 --> 02:50.540 The first argument is the netlink socket file descriptor which we have already created here. 02:50.570 --> 02:55.910 The second argument is the source address which contains the identity of the process. 02:56.030 --> 03:02.370 And the third argument is the size of the data structure which you are passing as the second argument. 03:02.390 --> 03:09.980 So using bind system call, this userspace program is actually telling the underlying operating system 03:10.400 --> 03:19.160 that hey, operating system, I am interested in receiving a netlink messages which are being sent to 03:19.160 --> 03:22.150 the userspace using this protocol number. 03:22.160 --> 03:22.760 Right? 03:22.760 --> 03:29.360 So through the second field in the bind system call, the userspace program is telling its identity 03:29.360 --> 03:37.010 to the operating system and it is telling the operating system that any message which is generated by 03:37.010 --> 03:44.990 the kernel subsystem using a netlink protocol number equal to the Netlink test protocol, which is 31, 03:45.020 --> 03:47.690 then I am interested in those messages. 03:47.690 --> 03:49.420 Please send it to me. 03:49.430 --> 03:56.180 So using bind system call the operating system has been told that any netlink messages which is generated 03:56.180 --> 04:02.450 by any kernel subsystem using protocol number equal to the netlink test protocol. 04:03.350 --> 04:08.750 The operating system is supposed to hand over those messages to the process. 04:08.750 --> 04:13.760 Who's process ID is specified as the second argument in this bind system call? 04:13.790 --> 04:16.100 That is this process itself. 04:16.100 --> 04:20.410 So not many people understand the mechanics of the bind system call. 04:20.420 --> 04:26.870 It is the way of telling the operating system that in what type of messages the user space program is 04:26.870 --> 04:28.010 interested in. 04:29.630 --> 04:36.410 We use bind system call not only in netlink sockets but everywhere, wherever you use sockets. 04:36.830 --> 04:39.320 So enough lecture on bind system call. 04:39.320 --> 04:40.970 Now let us move forward. 04:41.120 --> 04:48.380 Now we can start our infinite loop of the main thread and inside that infinite loop we can print the 04:48.380 --> 04:49.310 main menu. 04:49.340 --> 04:50.150 Right. 04:50.180 --> 04:54.200 You must have already written the program with some main menu kind of thing. 04:54.200 --> 04:54.800 Right? 04:55.220 --> 05:01.490 And then simply, we are asking the user to input his choice number and based on the choice number, 05:01.490 --> 05:04.880 we can do switch on these choices, right? 05:05.150 --> 05:11.300 So if the user presses the case, number one, we can simply invoke this code. 05:12.860 --> 05:20.930 So you can see that I am taking a character array and I am asking the user to input some string. 05:20.960 --> 05:28.820 We will going to send this string to the kernel space and finally we will invoke the greet kernel passing 05:28.820 --> 05:34.000 the socket using which we will going to send this message to the kernel space. 05:34.020 --> 05:40.020 The actual message which we are interested to send to the kernel space and the length of the message. 05:40.020 --> 05:40.680 Right. 05:40.680 --> 05:44.100 So we will discuss the implementation of this greet kernel API. 05:44.130 --> 05:45.630 It's very easy. 05:45.810 --> 05:54.180 And however, if the user chooses option number two, then we can simply exit our program before exiting 05:54.180 --> 05:54.840 our program. 05:54.840 --> 06:00.770 We should destroy our socket and every resource that your program occupies. 06:00.780 --> 06:06.120 So I have completed the implementation of the sending side of our user space program. 06:06.120 --> 06:10.020 And now let us discuss the implementation of this greet kernel API. 06:10.050 --> 06:11.530 It is very simple. 06:11.550 --> 06:18.540 This greet kernel API is simply a wrapper API over send netlink message to kernel API which we have 06:18.540 --> 06:19.820 already discussed. 06:19.830 --> 06:26.820 So if you want to implement this greet kernel API, you can see that it's very simple. 06:28.500 --> 06:36.060 This API simply invoke send netlink message to kernel and you can see that we are passing the netlink 06:36.060 --> 06:42.810 message type, which is our own custom type as Netlink message greet you can has defined this value 06:42.810 --> 06:50.760 to one and because we also need a response from the kernel space, therefore we are specifying the acknowledgment 06:50.760 --> 06:51.450 flag. 06:51.450 --> 06:52.260 Right. 06:53.160 --> 06:59.100 So remember this netlink message greet is a user defined constant value and you can just hash define 06:59.100 --> 07:00.480 it to one. 07:00.690 --> 07:06.630 This value will go as a netlink message type value in the netlink header to the kernel space. 07:07.260 --> 07:12.870 So with this, the implementation of the sending side of our user space program is complete. 07:13.500 --> 07:18.960 Now let us try to compile and see how this program behaves or works. 07:20.600 --> 07:26.380 Now, guys, we will see that whether our user space program is able to send message to the kernel space. 07:26.390 --> 07:32.210 So on the right hand side, in a separate window, I will monitor the content of the file kernel dot 07:32.210 --> 07:35.810 log into which all the print statements goes. 07:35.810 --> 07:42.320 And on the left hand side I will simply compile and run our user space program so you can see that our 07:42.320 --> 07:45.170 user space program present a main menu. 07:45.200 --> 07:48.260 I will choose the option number one to greet kernel. 07:48.260 --> 07:52.730 And now this user space program is asking me to input some string. 07:52.730 --> 07:56.330 So I will simply say hello, how are you? 07:56.810 --> 07:57.740 Kernel? 07:58.340 --> 07:59.180 Right. 07:59.300 --> 08:06.020 And just press enter and you can see on the right hand side that our kernel space is receiving messages 08:06.020 --> 08:09.320 and the message is hello, how are you kernel. 08:09.320 --> 08:11.570 So this is the message that I have received. 08:11.600 --> 08:18.020 So it simply means that the sending of a message from a user space to kernel space is now fully working. 08:18.020 --> 08:20.390 Let us try some more option. 08:20.390 --> 08:27.230 Now let us try one more attempt to send message to the kernel space and it works now. 08:27.230 --> 08:31.130 This time I have received I am fine message to the kernel space. 08:31.220 --> 08:31.970 Right. 08:31.970 --> 08:38.180 So now in the next lecture video we will see how our user space program can receive messages from the 08:38.180 --> 08:38.840 kernel. 08:38.840 --> 08:45.770 At this point of time our kernel space is sending message or reply back to the user space, but our 08:45.770 --> 08:51.680 user space doesn't have a provision or the code to actually receive the messages from the kernel space. 08:51.710 --> 08:52.460 Right? 08:52.460 --> 08:58.310 So in the next lecture video we will going to fix up the receiving part of our user space program.