Let us understand the new netlink code that was added to the loopback network driver we are developing in the previous article. We will look at specific snippets and understand what they mean.
The name of the netlink family we are attempting to create is “vnet_nl“. The version of the NETLINK family is 1 which is normally the case for various families created in Generic Netlink. The specific code is shown below:
The next element in code that deals with the specific family “vnet_nl” that we are attempting to create are the attributes and policies for the netlink family.
A netlink message has a netlink header and can consist of multiple sub-sections termed attributes. These attributes are placed in Type-Length-Value format. The actual memory layout of these are in Length(2 bytes), Type(2 bytes) and value (followed by padding if needed) format. The type of the attribute could be string, unsigned byte, unsigned integer, unsigned word etcetera. This is shown below in code:
The current netlink family has three attributes.
- A string attribute
- An unsigned integer 32 bit attribute
- A flag attribute – unsigned byte
The above attributes are defined in the netlink Policy as to how they will be verified and handled by the Netlink system. Our code only has a policy defined for the string. The interested reader can extend the same to include policies for the other two attributes. The policy for the string is shown below.
Next in code is to define the command that the virtual loopback driver will handle along with registering the function that will handle the command with the Netlink system.
The netlink_echo passed to genl_ops will handle the echo command in this case. If other attributes are added to the netlink policy, a developer of this code can use the same command to handle different attributes or add different handlers by adding new netlink commands.
A Generic netlink family can also broadcast specific events generated by the networking module to different clients who have registered to the netlink family. The interested client needs to register to the netlink family and request that they be part of a specific multicast group. In this case, the current generic netlink family defines one multicast group with the group name as “events”. The code however, currently does not publish any events to the multicast group. we can achieve that at a later date. The multicast group created for this netlink family is shown below:
The various parameters that are defined above are brought together in creating the various aspects of the netlink family as shown below:
The code for the “do_it” function which handles the NL_CMD_ECHO command is also shown below:
Once all the above is added, the generic netlink family is ready to be registered with the Generic netlink subsystem. This is performed in our code during kernel module initialization.
When the kernel module is unloaded, the netlink family is unregistered.
In the following article, we develop a sample application to invoke the NL_CMD_ECHO after the kernel module is loaded and the generic netlink family is registered during kernel module init.
Sample generic netlink application for virtual network loop back driver