mywiki:linux:generic_netlink
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| mywiki:linux:generic_netlink [2015/05/16 07:13] – [define operation] shaoguoh | mywiki:linux:generic_netlink [2019/09/15 18:55] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| Generic Netlink | Generic Netlink | ||
| - | | Reference | [[http:// | + | | Reference | [[http:// |
| ====== Generic Netlink Architecture ====== | ====== Generic Netlink Architecture ====== | ||
| Line 11: | Line 11: | ||
| Users who want to use a service query the controller to see if the service exists and to determine the correct channel number. | Users who want to use a service query the controller to see if the service exists and to determine the correct channel number. | ||
| + | |||
| < | < | ||
| Line 43: | Line 44: | ||
| </ | </ | ||
| + | |||
| + | |||
| + | ====== Data Structure of Generic Netlink ====== | ||
| + | |||
| + | |||
| + | {{: | ||
| + | |||
| + | |||
| + | One Family Data structure | ||
| + | < | ||
| + | | ||
| + | -- |Global attribute: attrbuf | | ||
| + | | ||
| + | | ||
| + | | | ||
| + | | | ||
| + | One Family -- | | ||
| + | | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | -- |operation list: | ||
| + | | ||
| + | | ||
| + | --| nth operation: unique command and its policy | | ||
| + | | ||
| + | |||
| + | |||
| + | </ | ||
| + | |||
| ====== Generic Netlink message format ====== | ====== Generic Netlink message format ====== | ||
| Line 63: | Line 95: | ||
| </ | </ | ||
| - | ====== Data Structure of Generic Netlink ====== | + | {{: |
| - | + | ||
| - | + | ||
| - | {{: | + | |
| + | {{: | ||
| ====== Procedure in kernel ====== | ====== Procedure in kernel ====== | ||
| + | |||
| ===== Register a family ===== | ===== Register a family ===== | ||
| Generic Netlink families are defined by the genl_family structure, which is shown below: | Generic Netlink families are defined by the genl_family structure, which is shown below: | ||
| Line 107: | Line 138: | ||
| </ | </ | ||
| - | ===== define | + | ===== Define |
| + | |||
| + | ==== Operation ===== | ||
| Generic Netlink operations are defined by the genl_ops structure, which is shown below: | Generic Netlink operations are defined by the genl_ops structure, which is shown below: | ||
| < | < | ||
| Line 146: | Line 179: | ||
| </ | </ | ||
| - | ===== Define Message structure | + | ==== Policy |
| - | + | when sending netlink messages the sender needs to adhere to the protocol format. | |
| - | Generic Netlink | + | The receiver of the message |
| < | < | ||
| - | struct genl_info | ||
| - | { | ||
| - | | ||
| - | | ||
| - | | ||
| - | | ||
| - | void * userhdr; | ||
| - | | ||
| - | }; | ||
| - | Fig: The genl_info structure | + | The nla_policy Structure |
| - | + | ||
| - | The fields are populated in the following manner: | + | |
| - | + | ||
| - | u32 snd_seq | + | |
| - | This is the Netlink sequence number of the request. | + | |
| - | u32 snd_pid | + | |
| - | This is the Netlink PID of the client which issued the request; it is important to note that the Netlink PID is not the same as the standard kernel PID. | + | |
| - | struct nlmsghdr *nlhdr | + | |
| - | This is set to point to the Netlink message header of the request. | + | |
| - | struct genlmsghdr *genlhdr | + | |
| - | This is set to point to the Generic Netlink message header of the request. | + | |
| - | void *userhdr | + | |
| - | If the Generic Netlink family makes use of a family specific header, this pointer will be set to point to the start of the family specific header. | + | |
| - | struct nlattr **attrs | + | |
| - | The parsed Netlink attributes from the request; if the Generic Netlink family definition specified a Netlink attribute policy then the attributes would have already been validated. | + | |
| - | The doit() handler should do whatever processing is necessary and return zero on success or a negative value on failure. Negative return values will cause an NLMSG_ERROR message to be sent while a zero return value will only cause the NLMSG_ERROR message to be sent if the request is received with the NLM_F_ACK flag set. | + | |
| - | </ | + | |
| - | + | ||
| - | + | ||
| - | ===== Define attribute policy ===== | + | |
| - | + | ||
| - | + | ||
| - | < | + | |
| - | The nla_policy Structure | + | |
| Generic Netlink attribute policy is defined by the nla_policy structure, which is shown below: | Generic Netlink attribute policy is defined by the nla_policy structure, which is shown below: | ||
| Line 195: | Line 195: | ||
| }; | }; | ||
| - | Figure 11: The nla_policy structure | + | Fig: The nla_policy structure |
| The fields are used in the following manner: | The fields are used in the following manner: | ||
| Line 224: | Line 224: | ||
| When the attribute type is one of the string types then this field should be set to the maximum length of the string, not including the terminal NULL byte. If the attribute type is unknown or NLA_UNSPEC then this field should be set to the exact length of the attribute' | When the attribute type is one of the string types then this field should be set to the maximum length of the string, not including the terminal NULL byte. If the attribute type is unknown or NLA_UNSPEC then this field should be set to the exact length of the attribute' | ||
| Unless the attribute type is one of the fixed-length types above, a value of zero indicates that no validation of the attribute should be performed. | Unless the attribute type is one of the fixed-length types above, a value of zero indicates that no validation of the attribute should be performed. | ||
| + | |||
| + | </ | ||
| + | |||
| + | |||
| + | ===== Define attribute ===== | ||
| + | |||
| + | |||
| + | < | ||
| + | |||
| + | |||
| </ | </ | ||
| Line 234: | Line 244: | ||
| It is also important to use unique attributes as much as possible. This helps make the most of the Netlink attribute mechanisms and provides for easy changes to the message format in the future. | It is also important to use unique attributes as much as possible. This helps make the most of the Netlink attribute mechanisms and provides for easy changes to the message format in the future. | ||
| + | |||
| + | ===== Define Message structure ===== | ||
| + | |||
| + | Generic Netlink message information is passed by the genl_info structure, which is shown below: | ||
| + | |||
| + | < | ||
| + | struct genl_info | ||
| + | { | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | void * userhdr; | ||
| + | | ||
| + | }; | ||
| + | |||
| + | Fig: The genl_info structure | ||
| + | |||
| + | The fields are populated in the following manner: | ||
| + | |||
| + | u32 snd_seq | ||
| + | This is the Netlink sequence number of the request. | ||
| + | u32 snd_pid | ||
| + | This is the Netlink PID of the client which issued the request; it is important to note that the Netlink PID is not the same as the standard kernel PID. | ||
| + | struct nlmsghdr *nlhdr | ||
| + | This is set to point to the Netlink message header of the request. | ||
| + | struct genlmsghdr *genlhdr | ||
| + | This is set to point to the Generic Netlink message header of the request. | ||
| + | void *userhdr | ||
| + | If the Generic Netlink family makes use of a family specific header, this pointer will be set to point to the start of the family specific header. | ||
| + | struct nlattr **attrs | ||
| + | The parsed Netlink attributes from the request; if the Generic Netlink family definition specified a Netlink attribute policy then the attributes would have already been validated. | ||
| + | The doit() handler should do whatever processing is necessary and return zero on success or a negative value on failure. Negative return values will cause an NLMSG_ERROR message to be sent while a zero return value will only cause the NLMSG_ERROR message to be sent if the request is received with the NLM_F_ACK flag set. | ||
| + | </ | ||
| + | |||
mywiki/linux/generic_netlink.1431731627.txt.gz · Last modified: (external edit)
