Re: RFC: a loadable plugin framework for external capture backends

[Robin Jarry via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: "Robin Jarry" <rjarry () redhat com>
>
> Date: Mon, 05 Oct 2026 11:12:40 +0200
>
> Guy Harris, Oct 04, 2026 at 19:43:
> > On Oct 4, 2026, at 2:11 AM, Robin Jarry <rjarry () redhat com> wrote:
> > > You would need PCAP_SUPPORT_GROUT, PCAP_SUPPORT_OVS, 
> > > PCAP_SUPPORT_VPP, etc. And you would be right where we started before 
> > > removing DPDK support, only worse. Each application would need to add 
> > > their backend code in the libpcap repository and maintain it every 
> > > time their API changes.
> >
> > At least for "everything is a package" platforms, such as most Linux 
> > distributions, that would not, in fact, be the case.
> >
> > Each backend provider would, as part of one of their packages, provide 
> > the backend as a library (shared, unshared, or both). Libpcap's 
> > autoconf script and CMakeLists.txt would check whether that library is 
> > present and, if so, set the appropriate PCAP_SUPPORT_xxx definition so 
> > that the entry in pcap.c's table of additional modules would include 
> > them, arrange that pcap-config and libpcap's .pc files link with those 
> > libraries for a static build if a static library for the backend is 
> > provided, and arrange that libpcap be linked with the backend library.
> >
> > The providers of the platform would have to include that backend, and 
> > arrange that it be present when libpcap is built, to ensure that it's 
> > available to software linked with libpcap.
>
> But that means you would need to link code at installation time. This 
> may be possible on some platforms, but in some cases, you may not even 
> have access to a linker nor any development headers.
>
> Also, keep in mind that most Linux platforms deliver GPG signed binary 
> packages. And every package contains a list of all its file fingerprints 
> (usually SHA-256). Re-linking libpcap.so would tamper that fingerprint.
>
> Also consider the case for image-based distributions (e.g. Fedora 
> Atomic, NixOS) where /usr is effectively read-only. You can only add new 
> packages using layers. Modifying files from other packages outside of 
> /etc is impossible.
>
> > The differences I see between what I understand Michael's proposal to 
> > be and your proposal are that:
> >
> > 1) Michael's proposal doesn't involve as much effort to avoid 
> >    malicious added mechanisms, as it's *less* flexible*;
> >
> > 2) your proposal makes it somewhat easier to add mechanisms on 
> >    "everything is a package" platforms and *significantly* easier to 
> >    add mechanisms on "libpcap is part of the core OS" platforms, and 
> >    makes it possible to allow D-Bus/{pick your DPDK-based 
> >    mechanism}/etc. support in libpcap to be available if and only if 
> >    the underlying mechanism is available, as it's *more* flexible.
>
> I am obviously biased, working for a company that sells support on such 
> a platform :-)
>
> For what it's worth, most Linux distros operate in the same model: 
> Debian (and its derivatives), Arch, Alpine, Fedora, NixOS, OpenWRT, etc. 
> The only ones that don't are usually build-from-source (e.g. Gentoo, 
> Void).
>
> --
> Robin
>
> # Do not pick the flowers.
>
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s