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

[Stephen Hemminger via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Stephen Hemminger <stephen () networkplumber org>
>
> Date: Thu, 1 Oct 2026 15:55:32 -0700
>
> On Thu, 1 Oct 2026 15:42:36 -0700
> Guy Harris <gharris () sonic net> wrote:
>
> > On Oct 1, 2026, at 2:53 PM, Robin Jarry via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
> >
> > > Michael Richardson, Oct 01, 2026 at 22:33:
> > >   
> > > > > - Failure behaviour. A plugin that is missing, unloadable, or reports   a mismatched ABI version must be a silent 
> > > > > no-op, never a fatal   error for libpcap or its callers.  
> > > >
> > > > I agree that it shouldn't call exit(2)!
> > > > I also agree that error strings need to be returned, not fprintf(stderr,..).
> > > > I'm not understanding the no-op :-)  
> > >
> > > The plugin loader could get an error back and optionally log it via strerror(). But since applications using 
> > > libpcap are supposed to not care about plugins, they should not be affected if one of them is broken.  
> >
> > I.e., if tcpdump or dumpcap starts using libpcap, a failed plugin (missing, version mismatch, etc.) just results in 
> > the type of interface it supports not being supported.
>
> I understand Robin's proposal is that libpcap itself gets installed with no plugin (maybe a demo).
> And each DPDK, grout, etc can ship a plugin that works with that version.
> If the plugin wants to change how it shares data with the application or subsystem, it can
> change the internal ABI at will. I.e it can use shared memory rings, or hidden unix sockets, or what
> ever it needs. And the plugin can be updated independently of libpcap.
>
> --- 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