Re: Initial libnl support committed

[Dan Williams <dcbw redhat com>]

On Fri, 2005-10-28 at 12:53 -0400, Robert Love wrote:
> On Fri, 2005-10-28 at 12:22 -0400, Dan Williams wrote:
> I have never heard of either libnl or libnlink until googling today.

Ah, I'd never heard of libnlink.  Hmm.

> So, here is my thinking:  If future NM needs are going to use more and
> more netlink (as we agree) and the netlink code utilized is complicated
> and not worth reimplementing, then using libnl seems sane.  But if we
> are talking about more of the same (saving a mere 30 lines), then I am
> not for it.  Since you imply that we are going to have greater and
> greater dependence on netlink, then I suspect the former is true and
> let's move forward.  I will package libnl for SUSE.  I would like to see
> more usage sooner rather than later, though, to validate libnl's use.

Yes.  In the immediate future, I imagine converting most of the system
backend stuff that calls out to /sbin/ip and whatnot to use libnl
instead.  That will actually be a net gain of code in NM, but will
decrease dependency on external programs, consolidate code, and make
that consolidated code more solid because it's used by everybody, not
just SUSE or Fedora or Gentoo.

Another rationale for libnl was to provide, through routing table
manipulation, the ability to do ICS/Internet Connection Sharing.
Granted, there have to be some changes internally to NM to support this
(some of which have already happened), but we also need to easily add
and remove specific routes from the table.  I seriously don't want to be
parsing output from /sbin/route or anything like that, and doing ioctl()
calls on all of this doesn't excite me either.

Another idea was to provide the illusion of an "active" device through
routing table priority, like windows does, but I thought I read
somewhere that the kernel doesn't actually honor routing table entry
priority.

As we grow out NetworkManager to support more and more use-cases, I
think the netlink code and routing table manipulation will become more
and more important.

Dan