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: Thu, 01 Oct 2026 23:01:47 +0200
>
> Hey Bill,
>
> Bill Fenner, Oct 01, 2026 at 22:49:
> > Hi Robin, thanks for starting this discussion. I'd like to throw another
> > idea into the mix: use the same API for plugins and "native" libpcap
> > implementation. A capture provider is a capture provider, and it could
> > be one registered by code compiled into the library or dynamically loaded
> > as a plugin - that is orthogonal.
>
> That is a great idea.
>
> > While not necessary, it would be an interesting proof of concept to
> > split out the platform's pcap-*.c into a plugin.
> >
> > If done well, this would eliminate any concern about the maintenance
> > burden - the API is the API is the API, and pcap-*.c using the same
> > API means that it's kept up to date.
>
> I completely agree with that approach. The migration of builtin backends
> to that "plugin" API would also serve as examples of how you can
> implement your own.
>
> The only caveat I can think of is that the builtin backends may need
> specific privileges that we may not want to expose to dynamically
> loadable third-party plugins?
>
> This could be worked around by having two ways to load plugins, either
> link them during build time and they are considered "trusted", or
> discover them at runtime and impose more drastic security requirements.
>
> What do you think?
>
> --
> Robin
>
> # Postage will be paid by addressee.
>
>
> --- 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