WEBVTT

00:05.050 --> 00:09.190
So guys, now let us discuss about Netlink message format.

00:09.430 --> 00:16.270
So user space application and kernel space exchange Netlink messages in well-defined format.

00:16.300 --> 00:17.080
Right.

00:17.150 --> 00:24.280
Any netlink message going from user space application to kernel space or from kernel space to user space

00:24.280 --> 00:29.410
application must be as per the netlink standard message format.

00:29.440 --> 00:37.000
You simply cannot push any message from kernel space to user space and vice versa in any random format.

00:37.030 --> 00:42.310
Your netlink message must be defined as per the netlink specification.

00:42.490 --> 00:48.460
The netlink messages must be formatted as per the Netlink standard message format.

00:50.280 --> 00:55.500
So a typical netlink message, when laid out in the memory, would look something like this.

00:55.740 --> 01:01.920
We have a netlink message header which is 16 bytes, followed by some padding bytes and then followed

01:01.920 --> 01:08.530
by the actual data which we are shipping from userspace to kernel space or vice versa.

01:08.550 --> 01:09.390
Right.

01:09.720 --> 01:13.930
Now let us discuss how does this netlink message header look like?

01:13.950 --> 01:18.800
So the structure which represents this netlink message header is very simple.

01:18.810 --> 01:21.270
It consists of these five fields.

01:22.290 --> 01:27.600
The first field of this netlink message header is the total length of this netlink message.

01:27.630 --> 01:28.350
Right?

01:28.350 --> 01:32.820
Including the payload, the padding and the netlink message header itself.

01:32.820 --> 01:33.540
Right.

01:33.570 --> 01:38.790
We will discuss the use case of the rest of the fields of this netlink message header in the coming

01:38.790 --> 01:40.740
lecture videos very shortly.

01:40.770 --> 01:41.550
Right.

01:41.880 --> 01:47.200
So this diagram represents a typical netlink message when laid out in the memory.

01:47.220 --> 01:54.040
If you have a payload data which needs to be sent to the other party, your payload data has to be appended

01:54.040 --> 01:59.980
with this Netlink message header and the fields of the Netlink message header has to be set appropriately

01:59.980 --> 02:02.800
as per the data that we are exchanging.

02:03.520 --> 02:11.950
Also note that both the parties here, both parties means user space or kernel space can exchange multiple

02:11.950 --> 02:15.430
Netlink message units cascaded one after the another.

02:15.430 --> 02:22.960
So you can see that in this diagram there are actually two units of netlink messages which are cascaded

02:22.960 --> 02:24.370
one after the another.

02:24.400 --> 02:30.310
The first unit is the following Netlink message that is starting from this Netlink message header up

02:30.310 --> 02:32.290
to the end point of its payload.

02:32.290 --> 02:39.190
And the second unit of Netlink message is the message which starts from here and it is the second unit

02:39.190 --> 02:41.290
and ends at its payload.

02:41.290 --> 02:42.010
Right.

02:42.720 --> 02:49.030
So, and there can be any number of netlink messages which could be appended, one after the another.

02:49.030 --> 02:49.880
Right.

02:49.900 --> 02:56.380
So the netlink mass is going from userspace to kernel space could be cascaded as well as it could be

02:56.380 --> 02:59.800
cascaded while going from kernel space to user space.

02:59.830 --> 03:00.580
Right.

03:01.930 --> 03:08.530
We will be having a scenario in our Netlink project where we shall be exchanging the cascaded netlink

03:08.530 --> 03:09.400
message.