Skip to content

[th/lldp] add libnm-lldp and replace systemd's sd_lldp_rx

Thomas Haller requested to merge th/lldp into main

We currently use the systemd LLDP client, which we consume by forking systemd code. That is a maintenance burden, because it's not a self-contained, stable library that we use. Hence there is a need for an individual library or properly integrating the fork in our tree.

Optimally, we would create a new nettools project with an LLDP library. That was not done because:

  • nettools may want to be dual licensed with LGPL-2.1+ and Apache. Systemd code is LGPL-2.1+ so it is fine for NetworkManager but possibly not for nettools.

  • nettools provides independent librares, as such they don't have an event loop, instead they expose an epoll file descriptor and the user needs to integrate it. Systemd and NetworkManager on the other hand have their established event loop (sd_event and GMainContext, respectively). It's simpler to implement the library on those terms, in particular porting the systemd library from sd_event to GMainContext.

  • NetworkManager uses glib and has various helper utils. While it's possible to do without them, it's more work.

The main reason to not write a new NetworkManager-agnostic library from scratch, is that it's much simpler to fork the systemd library and make it part of NetworkManager, than making it a nettools library.

The real question is of course what to do about our LLDP library.

  1. should we continue to use our systemd fork and re-importing the code indefinitely? That is cumbersome.
  2. should we continue to use our systemd fork and no longer import it? That seems to result in stale, unmaintained code, that does not integrate well with our NM code (*).
  3. should we create/wait-for a proper external library (nettools). That is much effort, and nobody steps up to do the work.
  4. create our own libnm-lldp libray.

(*) for example, our LldpNeighbor has a lot of overlap with sd_lldp_neighbor, and because we treat sd_lldp_neighbor as external, we cannot reconsile it. With our own NMLldpNeighbor type we are in full control and we could simplify LldpNeighbor (or even replace it entirely by `NMLldpNeighbor).

The branch does 4). This gives our own LLDP code and most flexibility. The downside is we stop benefiting from improvements from systemd.

Edited by Thomas Haller

Merge request reports