platform: create netlink messages directly without libnl-route-3

Instead of using libnl-route-3 library to serialize netlink messages,
construct the netlink messages ourselves.

This has several advantages:

- Creating the netlink message ourself is actually more straight
  forward then having an intermediate layer between NM and the kernel.
  Now it is immediately clear, how a platform request translates to
  a netlink/kernel request.
  You can look at the kernel sources how a certain netlink attribute
  behaves, and then it's immediately clear how to set that (and vice
  versa).

- Older libnl versions might have bugs or missing features for which
  we needed to workaround (often by offering a reduced/broken/untested
  functionality). Now we can get rid or workaround like _nl_has_capability(),
  check_support_libnl_extended_ifa_flags(), HAVE_LIBNL_INET6_TOKEN.
  Another example is a libnl bug when setting vlan ingress map which
  isn't even yet fixed in libnl upstream.

- We no longer need libnl-route-3 at all and can drop that runtime
  requirement, saving some 400k.
  Constructing the messages ourselves also gives better performance
  because we don't have to create the intermediate libnl object.

- In the future we will add more link-type support which is easier
  to support by basing directly on the plain kernel/netlink API,
  instead of requiring also libnl3 to expose this functionality.
  E.g. adding macvtap support: we already parsed macvtap properties
  ourselves because of missing libnl support. To *add* macvtap
  support, we also would have to do it ourself (or extend libnl).

1 files changed, 5 insertions, 6 deletions

diff --git a/src/nm-iface-helper.c b/src/nm-iface-helper.c
index 6ae19c5c7a..ecb67ea7bb 100644
--- a/src/nm-iface-helper.c
+++ b/src/nm-iface-helper.c
@@ -137,14 +137,13 @@ rdisc_config_changed (NMRDisc *rdisc, NMRDiscConfigMap changed, gpointer user_da
 
 	if (system_support == -1) {
 		/*
-		 * Check, if both libnl and the kernel are recent enough,
-		 * to help user space handling RA. If it's not supported,
-		 * we have no ipv6-privacy and must add autoconf addresses
-		 * as /128. The reason for the /128 is to prevent the kernel
+		 * Check, whether kernel is recent enough, to help user space handling RA.
+		 * If it's not supported, we have no ipv6-privacy and must add autoconf
+		 * addresses as /128.
+		 * The reason for the /128 is to prevent the kernel
 		 * from adding a prefix route for this address.
 		 **/
-		system_support = nm_platform_check_support_libnl_extended_ifa_flags () &&
-		                 nm_platform_check_support_kernel_extended_ifa_flags (NM_PLATFORM_GET);
+		system_support = nm_platform_check_support_kernel_extended_ifa_flags (NM_PLATFORM_GET);
 	}
 
 	if (system_support)