[libnl][netlink] bridge support
Nicolas Planel
nicolas.planel at enovance.com
Fri Oct 4 18:03:12 EDT 2013
Hi All, Thomas,
1/
I am currently working to implements python binding support on libnl.
Ultimately our goal is to implement an openstack L2 agent to use libnl API calls instead of fork()/execve() brctl commands.
2/
Basically libnl internal state didn't reflect the reality
So I have done some basic testing and see that the libnl is not supporting already instantiated bridge device.
For example :
# brctl addbr foo
# run testing-bridge.c
int r = rtnl_link_get_kernel(sk, 0, intf, &link);
int is_bridge = rtnl_link_is_bridge(link);
// rtnl_link_bridge_has_ext_info() response false too, see below
is_bridge is always false
as link->l_af_ops is NULL
basically because ifi->ifi_family == UNSPEC
In this case link_msg_parser() cannot call af_lookup_and_alloc() with right family value, and after nlmsg_parse()
3/ Workaround/Solution ?
3.1/ Implements link_info_ops for bridge too
add io_parse() callback
override the link->l_family
set link->l_af_ops
move callback() from af_ops to link_info_ops
=> May conflicts with vlan/vxlan ....
3.2/ On kernel side : set the ifi_family for every link based on flags (for bridge dev->flags & ...BRIDGE...)
=> very ugly
3.3/ On link_msg_parser()
af_lookup_and_alloc()
...
nlmsg_parse()
...
if (tb[IFLA_LINKINFO]) {
...
kind = ...
...
if (!af_ops && (af_ops = af_lookup_and_alloc(link, kind))) {
link->l_af_ops = af_ops;
}
}
Let me know what do you think about this and how we can go forward with this.
Regards,
Nicolas PLANEL
More information about the libnl
mailing list