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
