So guys, now let us discuss about Netlink message format.
So user space application and kernel space exchange Netlink messages in well-defined format.
Right.
Any netlink message going from user space application to kernel space or from kernel space to user space
application must be as per the netlink standard message format.
You simply cannot push any message from kernel space to user space and vice versa in any random format.
Your netlink message must be defined as per the netlink specification.
The netlink messages must be formatted as per the Netlink standard message format.
So a typical netlink message, when laid out in the memory, would look something like this.
We have a netlink message header which is 16 bytes, followed by some padding bytes and then followed
by the actual data which we are shipping from userspace to kernel space or vice versa.
Right.
Now let us discuss how does this netlink message header look like?
So the structure which represents this netlink message header is very simple.
It consists of these five fields.
The first field of this netlink message header is the total length of this netlink message.
Right?
Including the payload, the padding and the netlink message header itself.
Right.
We will discuss the use case of the rest of the fields of this netlink message header in the coming
lecture videos very shortly.
Right.
So this diagram represents a typical netlink message when laid out in the memory.
If you have a payload data which needs to be sent to the other party, your payload data has to be appended
with this Netlink message header and the fields of the Netlink message header has to be set appropriately
as per the data that we are exchanging.
Also note that both the parties here, both parties means user space or kernel space can exchange multiple
Netlink message units cascaded one after the another.
So you can see that in this diagram there are actually two units of netlink messages which are cascaded
one after the another.
The first unit is the following Netlink message that is starting from this Netlink message header up
to the end point of its payload.
And the second unit of Netlink message is the message which starts from here and it is the second unit
and ends at its payload.
Right.
So, and there can be any number of netlink messages which could be appended, one after the another.
Right.
So the netlink mass is going from userspace to kernel space could be cascaded as well as it could be
cascaded while going from kernel space to user space.
Right.
We will be having a scenario in our Netlink project where we shall be exchanging the cascaded netlink
message.