[bug-inetutils] Re: route

[Debarshi Ray]

>    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