> In other words, libnl is not widley used, so it would be bad for > inetutils to depend on it if it is a external third party library. > > That is a valid practical advantage for avoiding libnl, > but if there are sufficient benefits to using libnl, > they could override this advantage. > > On the other hand, if many important distros don't contain libnl, > that is a much stronger practical argument for not using it, > at least not using it now. I can't tell for certain from > the messages whether that is the case.
When one judges the popularity of libnl, one has to consider the following: Users have traditionally been using things like route and netstat to deal with the routing table from the command line. However implementations of these, especially route, differ wildly on different OSes and internally they are mostly based on ioctl calls, /dev/kmem, /proc/net/..., etc.. Recently the *BSDs are migrating to using PF_ROUTE, which is the recommended procedure for the *BSD kernels. In fact I have spoken to the FreeBSD people and plan to help them re-write their netstat and route implementations use PF_ROUTE more widely. On the Linux kernel's side of things, the kernel community seems to be moving towards a newer generation of tools, like iproute (ip & ifcfg) and iw to replace the older route, ifconfig and iwconfig implementations for the Linux kernel from the net-tools project. The older ones used the ioctl and /proc/net/... approach, while the newer incarnations are using PF_NETLINK either directly or indirectly (eg., libnl). Quoting from the iproute page (http://www.linuxfoundation.org/en/Net:Iproute2): [...] "Most network configuration manuals still refer to ifconfig and route as the primary network configuration tools, but ifconfig is known to behave inadequately in modern network environments. They should be deprecated, but most distros still include them. Most network configuration systems make use of ifconfig and thus provide a limited feature set. The /etc/net project aims to support most modern network technologies, as it doesn't use ifconfig and allows a system administrator to make use of all iproute2 features, including traffic control." [...] If we now look at NetworkManager (an example of a GUI tool part of today's GNOME desktop) we find that it started off by directly spawning ip(8) from the iproute suite to do much of its work. It has over time shifted to using libnl instead of directly spawning other executables. Using libnl instead of directly using PF_NETLINK has some advantages. You may have noticed that I started off by directly dealing with PF_NETLINK. It removes us from the burden of dealing directly with the PF_NETLINK sockets, which are datagram oriented. Personally I prefer dealing with library functions that take in variables and return exit status than directly dealing with sockets, sequence numbers, etc.. >From a more pratical and broader stand point, take the example of my preliminary code which is directly dealing with PF_NETLINK. It worked fine on Linux 2.6.25, but the 'route add' functionality broke on Linux 2.6.26. 'route show' and 'route del' did not break. It is apparently due to a bug in our handling of PF_NETLINK. Such things become much easier when we are using a library, which abstracts out the arcane less documented corners, and is maintained by members of the respective kernel communities. Till now, I have not encountered anything corresponding to libnl for the *BSDs which will make it easier to deal with PF_ROUTE. So I am dealing with PF_ROUTE directly at the time of writing. Saying that only two programs are using such a library is not a very good argument, since there are not many programs apart from the ones we have discussed already that will be needing it. Regards, Debarshi Regards, Debarshi
