route: support for retrieving a link's permanent address. #362
Conversation
| @@ -1292,6 +1292,7 @@ global: | |||
| rtnl_link_bridge_set_vlan_stats_enabled; | |||
| rtnl_link_inet6_get_conf; | |||
| rtnl_link_info_ops_get; | |||
| rtnl_link_get_perm_addr; | |||
There was a problem hiding this comment.
3.8 is already released. That means the section "libnl_3_8" must not be changed anymore.
Add a new libnl_3_9 section at the bottom of the file.
| * | ||
| * @return Permanent hardware address or NULL if not set. | ||
| */ | ||
| struct nl_data *rtnl_link_get_perm_addr(struct rtnl_link *link) |
There was a problem hiding this comment.
compare to rtnl_link_get_addr. That one returns a struct nl_addr type. I think that should also be used for the perm-addr, or why not?
| if (link->ce_mask & LINK_ATTR_PERM_ADDR) { | ||
| uint8_t *addr = nl_data_get(link->perm_addr); | ||
| nl_dump(p, "hw %x:%x:%x:%x:%x:%x ", addr[0], addr[1], addr[2], | ||
| addr[3], addr[4], addr[5]); |
There was a problem hiding this comment.
cannot blindly access the addr array. Must make sure that there are 6 elements there (and do something in case there isn't).
| @@ -358,6 +359,10 @@ static int link_clone(struct nl_object *_dst, struct nl_object *_src) | |||
| if ((err = rtnl_link_sriov_clone(dst, src)) < 0) | |||
| return err; | |||
|
|
|||
| if (src->perm_addr) | |||
| if (!(dst->perm_addr = nl_data_clone(src->perm_addr))) | |||
| return -NLE_NOMEM; | |||
There was a problem hiding this comment.
please squash the commits. This second commit just fixes a bug in the previous commit.
| @@ -73,6 +73,7 @@ struct rtnl_link { | |||
| int l_ns_fd; | |||
| pid_t l_ns_pid; | |||
| struct rtnl_link_vf *l_vf_list; | |||
| struct nl_data * perm_addr; | |||
There was a problem hiding this comment.
also needs to be handled in link_compare().
|
I'm sorry for keeping the flow-up delayed. I'm hoping to complete this feature soon. Any updates that should be taken into consideration after the release of 3.9? |
Don't worry. Contribute at the pace that works best for you. Thank you!
No? I think I don't understand the question. |
|
Sorry for confusing question. I meant to ask if there something a should take into account while implementing requested changes. For example in libnl-route-3.sym section libnl_3_9 already exist due to release of 3.9, so i should name new section 3.10 right? |
Yes, the section to be extended is the one from the next (future) release. At this time, that is |
Not sure about libnl-route-3.sym. Please check.