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

Roy Marples, le mar. 26 mai 2026 23:05:07 +0100, a ecrit:
>  > 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.

Yes.

> Please explain this BSD-ish interface Hurd has that say Linux does not?

All kinds of details in the headers. I don't remember by heart all
kinds, but e.g. the presence of sin_len in the sockaddr structure. Such
kind of detail which make Linux essentially different from BSD. See the
glibc structure: linux is inside unix/sysv, and not inside unix/bsd.

As I already explained on IRC, possibly the benefit of defining BSD is
nowadays smaller than not defining it. But if we stop defining the BSD,
*do* *expect* *breakage* in all kinds of odd places. Don't ask me to fix
these.

>  > > 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?

There is no single "stack" on the Hurd. You have various translators
which can implement devices, tcp/ip stacks, firewalls, etc. There is not
central piece there. BPF snooping can make sense in all kinds of
different places, which can be controlled by root or user, etc.

> And more importantly ... why?

Just random example: allow the user to start a vpn without having to ask
root. And then be able to tell exactly which process should be using it
or not. Be able to give access to a card to a process/subhurd/whatever.
The possibilities are really ample.

Samuel