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
