So guys resuming the discussion of the implementation of our Linux kernel module from the same point
where we had left last time.
So we discussed that whenever our Linux kernel module is going to receive a message from the userspace,
then it is this function which will going to be invoked in the kernel space, Right?
And the message or the data which is coming from the user space will be present in the data member of
this socket buffer which is passed as an argument to this function.
So we will discuss the implementation of this function because in this function we will going to receive
the data coming from the user space, we will process the data and not only that, we will going to
reply back to the user space with the reply.
So first of all, let us print something so that we would know that this function has been actually
invoked as a result of receiving a data from the user space.
Now let us declare some local variables which we will be using in this function.
So you can see that we have just declared a variable of type netlink message header.
Right.
So Netlink header receive variable will be a variable which will be used to point to the data which
has been received from the user space.
If you recap, always remember that the data is exchanged between the user space and the kernel space
via netlink sockets in the form of the netlink message header appended by the payload.
Right.
So what you see on the screen is actually the format of the message that is exchanged between user space
and kernel space via netlink sockets.
So it simply means that whatever data we have received from the user space is pointed by the data member
of this data structure.
We need to typecast that data into a netlink message header type and therefore Netlink had to receive
is a variable which points to the start of the Netlink message header.
Of course this netlink message header is appended by the payload.
So now we have an access to all the fields of the Netlink message header which is obtained from the
user space.
Now you will be interested to see all the fields of this netlink message header which the user space
application has send to your Linux kernel module.
For that we can invoke an API netlink message dump.
Now this is not a standard API.
It is an API that was written by you as a part of assignment before this lecture video.
Right.
Now remember that the Netlink message header contains one of the field called Port ID We discussed in
the theory section.
Right.
So now let us read that port ID and save in some local variable so you can see that the netlink message
underscore PID is a member of Netlink message header which stores the port ID of the userspace application.
And now you can simply print some information so that you would know what is going on behind the scenes.
That is, this information would surely help you in debugging your code in case.
You do not experience the expected output as a part of testing your code.
So we have simply printed some message that the port ID of sending userspace process and you are simply
printing the port ID of the process which sends the data to your kernel space.
Now let us take one more local variable, which is actually a pointer to the payload.
Right now you already have an access to the Netlink message header.
How can you get an access to the payload which is present behind this netlink message header?
So you can easily obtain the access to the payload by using an standard API which is provided by Linux
kernel.
So it is this API that is netlink message underscore data and you simply pass the pointer to the netlink
message header.
This API will return a pointer to the start of the payload which is present behind this netlink message
header.
Right.
So userspace data represents the payload which is sent from the userspace to the kernel space.
And of course you also want to know how many bytes of data the userspace application had sent to the
kernel space that you can simply obtain from the land number field of the socket buffer.
Right.
So it means that the user space application has send these many bytes of data to the kernel space.
Remember that these bytes of data also include the length of the netlink message header.
And again, we can print some useful information.
For example, I would choose to print a message that our Linux kernel module would print the following
information message received from the user space and then printing the actual payload which our Linux
kernel module has obtained from the user space.
And then printing the length of the data which our Linux kernel module has received.
And then again printing the netlink message length field which is present in the Netlink message header.
Then of course this value and this value must be same, right?
Because both of these data members actually carries the length of the data which the userspace application
has sent to the kernel space.
Right.
So both these members must print the same value.
So you can see that this completes the step of how our Linux kernel module can read the data which is
sent from the userspace.
Right.
Now that we have an access to the userspace data as well as we also know how much data the userspace
application has sent, our Linux kernel module as per the business logic can perform any operation on
this userspace data as per the requirement or problem statement.
Right.
So these are the steps of receiving a message from the userspace and processing the message.
Now next we will going to discuss that how kernel space can reply back to the user space.