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: Sat, 03 Oct 2026 11:57:20 +0200
>
> Michael Richardson, Oct 02, 2026 at 16:10:
> > If the loader is off by default, and the end-user uas to recompile 
> > libpcap to enable plugins, (and the plugin has to be compiled), then 
> > why do we need it dynamic?
> >
> > If someone (redhat, ubuntu, ...) are shipping DPDK-enabled distros 
> > with some application (OVS, whatever), then you'd build libpcap that 
> > way there. It's what ships as libpcap in RHEL, U-server LTS 26, ... 
> > that concerns us. (and... it's not just the actual bugs anymore, it's 
> > the slop that might get triggered...)
>
> For packaging purposes, you cannot know in advance which plugins will be 
> installed and you generally don't want to compile the plugins as part of 
> libpcap that is the whole point of our proposal. They wouldn't be real 
> "plugins" if that was necessary. We would go back to either a downstream 
> maintained fork/patch or a built-in backend disabled by default (like 
> DPDK was before I removed it for 0.11.0).
>
> So the libpcap core must be one package, and other independent packages 
> must be able to drop their respective plugins for libpcap to discover at 
> runtime. Not at build time.
>
> However, the very fact that you *have* plugin support in libpcap could 
> be opt-out at build time, for any reason you might have (e.g. security). 
> In that case, plugins would not be discovered/loaded at all.
>
> Am I making sense here?
>
> --
> Robin
>
> # Read the fine print.
>
>
> --- 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