Re: Fwd: [PATCH 1/6] New libpcap BPF backend

Hi Samuel

From: Samuel Thibault <[email protected]>
To: "Joan Lledó"<[email protected]>
Cc: "Roy Marples"<[email protected]>, "martin-ericracine"<[email protected]>, "bug-hurd"<[email protected]>
Date: Tue, 26 May 2026 22:20:22 +0100
Subject: Re: Fwd: [PATCH 1/6] New libpcap BPF backend

 > Hello, 
 >  
 > Joan Lledó, le sam. 23 mai 2026 12:14:45 +0200, a ecrit: 
 > > El 19/5/26 a les 23:26, Roy Marples ha escrit: 
 > > 
 > > > My main concern is for patch #3. Why does Hurd provide a #define for BSD - it's clearly not a BSD and I see this as a bug that should be resolved outside of dhcpcd. 
 > > 
 > > Totally agree :). I also don't know why the Hurd defines `BSD` and then 
 > > doesn't implement BSD interface. 
 >  
 > It does. 
 >  
 > It doesn't implement all of them, sure, it's almost by definition since 
 > as soon as BSD introduces a new one, it's not implemented. But then 
 > that's the same for any past BSD version. And for all discrepancies 
 > between OpenBSD/FreeBSD/NetBSD. 
 >  
 > But really, the Hurd exposes a very BSD-ish interface.

For reference, we are talking about /usr/include/bits/param.h from glibc.

Please explain this BSD-ish interface Hurd has that say Linux does not?
At best Hurd has sa_len in sockaddr (not that I can find the actual struct in glibc).

Beyond that I'm struggling to see any BSD exposed to userland.

route(4)? no
sockaddr_dl? no (but glibc defines AF_LINK anyway and other IOCTLS without structs)
getprogname()? no
kqueue? no

Should we also talk about the missing headers every BSD ships that Hurd lacks?
Like say net/bpf or sysctl?
Or the missing guards (can't mix if_ether.h or ethernet.h and I only need ethernet.h on Hurd)

SunOS (IllumOS, Solaris, etc) and macOS don't define BSD which makes my life fairly easy.
So please, tell me about this very BSD-ish interface I am missing in Hurd.


 >  
 > > In the case of BPF, you can get some 
 > > further info here: 
 > > 
 > > https://darnassus.sceen.net/~hurd-web/open_issues/bpf/ 
 > > 
 > > It was considered to implement BSD interface via BPF translator and finally 
 > > discarded. IMO implement BSD interface would be optimal in order to get max 
 > > compatibility with existing packages, 
 >  
 > Yes, but at the expense of making it *much* less flexible. 
 >  
 > Having a bpf translator on /dev/bpf means that is has to know about 
 > *all* network devices in some way. That cannot include tunnel devices 
 > that can be created on the file in any place of the filesystem space.

OK, I'll bite as I know about networking (duh).
BPF sits in the middle of the network - no driver should touch it directly other than ones that amalgamate interfaces such as a bridge.
BPF itself knows about no other interfaces, it just re-injects back into the stack.
What does hurd do differently? And more importantly ... why?
 
 > Since there is a portability library which can be taught to open the 
 > device node itself and set up some bpf filtering directly there, it can 
 > be leveraged to keep the maximum flexibility. 

Yes, if libpcap upstream can be convinced to accept the selectable_fd() patch then everyone is happy.
Overwise, I'll whack the equivalent into dhcpcd and call it a day.
Now I've split the BPF internals out into files, bpf-hurd.c is possible.

Roy