Re: Guidance to implement io_select on network devices

From: Samuel Thibault <[email protected]>
To: "Roy Marples"<[email protected]>
Cc: ""Joan Lledó""<[email protected]>, "bug-hurd"<[email protected]>, "martin-ericracine"<[email protected]>
Date: Fri, 12 Jun 2026 00:53:48 +0100
Subject: Re: Guidance to implement io_select on network devices

 > Hello, 
 >  
 > Roy Marples, le jeu. 11 juin 2026 09:44:50 +0100, a ecrit: 
 > > From: Samuel Thibault <[email protected]> 
 > >  > Roy Marples, le dim. 07 juin 2026 18:55:40 +0100, a ecrit: 
 > >  > > I really dislike the small timeout just to add a cancellation point as it means 
 > >  > > there is a lot of context switching going on just because of this. 
 > >  > 
 > >  > Why the small timeout? doesn't cancellation interrupt mach_msg with an 
 > >  > infinite timeout, provided that we pass MACH_RCV_INTERRUPT. If not, it 
 > >  > rather looks to me like a bug to be fixed. 
 > > 
 > > mach_msg is NOT a pthreads cancellation point when passed MACH_RCV_INTERRUPT. 
 > > I would agree this is a bug that should be fixed. 
 > > 
 > > The workaround for the time being is to set pthreads async cancellation but disable 
 > > cancellation around routines that manipulate resources - such as mutex lock/unlock 
 > > and mallocing a new msg buffer. 
 >  
 > One can set async mode only around the mach_msg call for instance. 

That would be an option as well, but the more I learned about pthreads for the I lean
towards marking critical sections of my code as non cancellable.

 > > The big benefit for me NOT using libpcap for this is that I discovered that dhcpcd's 
 > > ARP BPF code is too big to fit in the Mach kernel. 
 >  
 > The Mach kernel? The network drivers rather live in netdde, and the bpf 
 > support comes from libbpf inside the hurd repository. If there is a 
 > limitation there it can very probably be lifted. 

https://cgit.git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/include/device/bpf.h#n195
https://cgit.git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/include/device/net_status.h#n80

That is the limitaton I'm talking about.
Looks like it's already been lifted once.

Here's the equivalent limit in NetBSD
https://nxr.netbsd.org/xref/src/sys/net/bpf.h#67

Roy