WEBVTT

00:05.360 --> 00:12.470
So, guys, once we get ourselves familiar with the basics of netlink socket programming, rest of the

00:12.470 --> 00:18.380
concepts of the netlink, we will going to learn through one unified Netlink project, right?

00:18.410 --> 00:24.170
So in this project, as you can see in the diagram, we will have a userspace application which will

00:24.170 --> 00:29.750
be communicating with the routing table which is present in the kernel space, right?

00:29.750 --> 00:34.730
So we will call this routing table as kernel routing table manager subsystem.

00:36.050 --> 00:42.260
So in this project we shall be discussing the communication between user space application and routing

00:42.290 --> 00:45.140
table kernel subsystem as an example.

00:46.420 --> 00:53.590
Userspace application actions will be to perform Crud operations on this routing table sitting in the

00:53.590 --> 00:54.730
kernel space.

00:54.760 --> 00:55.500
Right.

00:55.510 --> 01:02.320
That is our user space application will issue the order to create an entry to delete an entry or to

01:02.320 --> 01:05.830
update an existing entry in this routing table.

01:05.830 --> 01:09.730
And remember, this routing table is present in the kernel memory.

01:10.490 --> 01:17.420
So on the kernel space side, we will going to write a Linux kernel module which will behave as a routing

01:17.450 --> 01:20.690
table manager residing in the kernel space.

01:20.720 --> 01:27.680
It means that our this Linux kernel module will be in charge of this routing table data structure.

01:27.680 --> 01:28.400
Right.

01:29.610 --> 01:36.390
All Linux kernel module will going to receive and process the orders coming from the application.

01:36.390 --> 01:45.480
Right now, since in this project we have taken routing table as an example representing routing table

01:45.480 --> 01:47.520
manager kernel subsystem.

01:48.480 --> 01:53.550
Same netlink communication semantics applies to other kernel subsystems as well.

01:53.580 --> 02:00.240
It means that once we learn how to set up a netlink based communication between userspace application

02:00.240 --> 02:08.370
and any kernel subsystem, the same rule applies for communication between userspace application to

02:08.370 --> 02:10.830
any other linux kernel subsystem.

02:10.830 --> 02:11.550
Right.

02:12.120 --> 02:18.660
So going forward in this course, we shall explore netlink socket based communication between userspace

02:18.660 --> 02:24.990
and kernel space by developing userspace application which will interact with our Linux kernel module,

02:24.990 --> 02:29.670
which is in charge of our routing subsystem of the kernel.

02:29.880 --> 02:36.600
Once we understand how netlink based communication work using one subsystem as an example.

02:37.080 --> 02:39.300
So what is that one subsystem?

02:39.300 --> 02:45.510
That one subsystem is nothing, but it is the routing table manager which is represented by our Linux

02:45.510 --> 02:46.410
kernel module.

02:46.620 --> 02:53.610
So we can make use of our knowledge to develop userspace application which can interact with any other

02:53.610 --> 02:55.530
kernel subsystems, right?

02:55.560 --> 02:58.890
The principles and the rules of communications are same.

02:58.890 --> 03:05.820
What changes are only the netlink messages that are being exchanged between userspace application and

03:05.820 --> 03:09.810
the kernel subsystem with which the application is interacting.

03:09.990 --> 03:16.090
Along the way, we shall also learn various other techniques of communication, such as TLB based communication

03:16.090 --> 03:18.210
or event based communications.

03:18.220 --> 03:18.880
Right?

03:18.880 --> 03:22.600
So now it's time to write our first Netlink program.