So guys, now let me introduce Netlink sockets.
We will start with understanding the design and architecture of Netlink sockets.
So Netlink sockets, as I stated, are specially designed and created to facilitate clean bidirectional
communication between user space and kernel space.
Right.
Other techniques can also be used for user space to kernel space communication, but those techniques
were actually not invented for communication between user space and kernel space.
Right.
Other techniques are such as ioctls device files, system calls, etcetera.
Right.
So whenever there is a requirement only to do bi directional communication between the application and
the user space, the netlink socket is the first choice that you should use.
You won't write a new system call only to carry out some data exchange between an application and the
kernel space.
Right.
Writing a system call requires you to actually modify the Linux kernel code and recompile and rebuild
the entire Linux kernel code.
Secondly, you just don't write system call unless you have a very fairly good reason because system
calls are actually general purpose calls and those should be used by every other application that is
running on the Linux platform just to meet the requirement of one application.
We usually don't go for writing a new system call altogether.
Device files have been invented especially to write device drivers.
Ioctls are also a facility that is provided by the kernel to set up the communication between the application
and the device drivers, which are sitting on the kernel side.
So given a problem statement P and you are asked that you have to solve the problem.
P And in order to solve the problem, P you have to set up the communication between user space and
kernel space.
Right now you are asked the question that which technique would you employ in order to set up the communication
between user space and kernel space?
Would you choose system calls?
Would you choose device files?
Would you choose ioctls?
Or would you choose any other mechanism?
The answer is that you would be able to choose the most promising and appropriate mechanism for setting
up the communication between user space and kernel space.
Only when you would be knowing how each of these facilities works behind the scenes.
Once you know how the communication is set up, using all of these mechanisms provided by a kernel subsystem,
you would be able to pinpoint out the advantages and disadvantages of each of these facility, given
the type of communication that you need to set up between user space and kernel space.
Right.
So in this section of the course anyway, we will going to continue with the netlink sockets.
So this is an open question.
And I leave it for you because I do not know how many of you are familiar with these terms.
That is ioctls device files or system calls, right?
Probably in my follow up courses on Linux kernel.
I will going to cover ioctls device files system calls and see how these techniques are superior or
inferior with respect to each other.
But anyways, now let us come back to our discussion on netlink sockets.
So a socket based technique was developed to build the unified interface using which userspace application
can interact with various kernel subsystems.
Now note the important terms here the unified interface.
No other communication techniques such as these provides this strength of unified interface of communication.
And also note that another term is various kernel subsystems.
Using netlink sockets, the userspace application can communicate with any component of the kernel subsystem.
I assume that at least once in your life you have written a socket based program, so we usually create
a socket using socket system call.
The first argument to this socket is the address family of the socket.
The second argument is the communication type, which could be datagram based or stream based.
And the third argument to this API is a protocol used for the communication.
So the third argument is the protocol number.
So socket interface of communication is actually a unified way of communication because depending on
the argument passed to the socket API, we can set up the communication properties, that is whom we
are communicating, what we are communicating and how we are communicating, right?
So all these three parameters we can control by only specifying the three arguments to this socket API.
To understand this point better.
Let me give you an example.
If you have ever written a socket program, then you must have passed the third argument as UDP.
If you want it to set up a UDP based communication.
Otherwise, the third argument you had passed as TCP.
If you set up a TCP based communication between the two parties, right?
So you are actually controlling the behavior of the communication by only specifying the arguments passed
to this socket API.
So kernel designers thought of using a unified interface such as socket in order to facilitate the communication
between user space applications and various kernel subsystems.
So now let us discuss in the next slide that why socket interface is called as unified interface of
communication.
By actually taking an example that what are the various kernel subsystems that are application can communicate
using sockets.