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

Hi Joan


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

 > Hi Roy, 
 >  
 > I'm adding the Hurd mailing list to CC. 

I'm not subbed to the list, so please CC me on any relevant replies.
Thanks in advance!

 >  
 > El 19/5/26 a les 14:21, Roy Marples ha escrit: 
 > > Hi 
 > > 
 > > Thanks for the patch, I've merged it here: 
 > > https://github.com/NetworkConfiguration/dhcpcd/ 
 > > commit/6ae07424aff786e0feb83f4f008725716bd7c5ce <https://github.com/ 
 > > NetworkConfiguration/dhcpcd/commit/6ae07424aff786e0feb83f4f008725716bd7c5ce> 
 > > 
 >  
 > I didn't open a PR for the patches because I'm still not 100% sure these 
 > are going to be the final patches, since I'm still waiting for this PR 
 > to be merged by libpcap maintainers: 
 >  
 > https://github.com/the-tcpdump-group/libpcap/pull/1565 
 >  
 > But thanks anyway, I don't think I'll need to change any of the patches, 
 > but who knows. 
 >  
 > > This actually triggered a fair bit of work, splitting out the BSD and 
 > > DLPI specifics new files. 
 > > I also optimised the pcap code a little with the final result here: 
 > > https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/bpf- 
 > > pcap.c <https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/ 
 > > bpf-pcap.c> 
 > > 
 > > As part of this, I did actually patch libpcap to support BSD write 
 > > filter and lock mechanisms but it seems upstream is resistant to this 
 > > change because it's BSD only even though it provides a mechanism to 
 > > harden the use of libpcap in a public facing application. 
 > > https://github.com/the-tcpdump-group/libpcap/pull/1683 <https:// 
 > > github.com/the-tcpdump-group/libpcap/pull/1683> 
 > > 
 > > So, my question is how hard would it be to add BPF write filtering and 
 > > filter locking to GNU/Hurd? 
 >  
 > Maybe others in the Hurd list answer this, they can probably answer 
 > better than me. 
 >  
 > The first idea that comes to my mind is to actually create the BPF 
 > translator for the hurd, installed at /dev/bpf, following the BSD 
 > interface. That way we could implement such operations via RPCs or via 
 > ioctls. That way, both libpcap and dhcpcd could use their existing BSD 
 > backends for the hurd. 
 >  
 > But we don't have such translator as for today, so, unless gnumach 
 > supports such features, I don't know how can we implement 
 > pcap_setwritefilter() and pcap_lockfilter() on libpcap for the hurd. 
 >  

No problem.
My idea was just that if any other OS supported BSD write filtering for BPF then they would be more open to merge it.

 >  
 > > Hopefully the rest of the patches won't be so onerous! 
 > > 
 >  
 > Please take into account the Patch 5 about the `./configure` has some AI 
 > generated code, since I don't really know much about shell scripting. 
 > 

It's not a problem, I can see what it's doing well enough.
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.

I still don't have a Hurd VM yet - it doesn't work at all on my Macbook Neo via QEMU (emulating x86_64) and while I do get some progress on my NetBSD host it can't find any disks to install to. Likely Hurd lacks virtio foo and I need to update my qemu start script to accomodate. Someone also recommended using i386 rather than x86_64.

I'm loath to commit patches I can't test as well so it's probably a good time to chat before doing anything else :)

Thanks

Roy