Hello, Joan Lledó, le dim. 07 juin 2026 18:51:21 +0200, a ecrit: > The alternative that should be accepted upstream implies implementing > `io_select` on network devices in gnumach. I'm not working on anything else > right now, so I might try, but, how difficult would be?, is it doable? If > so, I'd need some basic guidance on how to start doing this.
Roy Marples, le dim. 07 juin 2026 20:24:18 +0100, a ecrit: > Ah, to be clear, I think that providing a means to convert something mach into > something selectable Checking more precisely how the current networking device work, they actually directly send their packets as mach messages, without an RPC like device_read() or such, which makes sense for efficiency (no need for a round-trip), but then io_select() is meaningless there, with that interface, it's rather that we'd just want to wait for a message to be available. I tried to think how select() could be taught to do this, but to be able to wait on several fds at the same time, it will consume the message anyway, since that's how it works for the io_select() protocol. Another way could be to add along mach_msg() a variant that only waits and does not dequeue anything. We'd however want a way to efficiently express which port(s) have some message available. Another way to get a selectable fd would be to add in libmachdevdde a (less efficient) variant of device_set_filter that, instead of making netif_rx_handle send the packet as a message, queues it and waits for an io_read() call to provide the packet, and then it can implement io_select() to synchronize with the queue emptiness. Then comes a question of the queue size and such, but that's still better than going through a pipe. Roy Marples, le dim. 07 juin 2026 18:55:40 +0100, a ecrit: > I need to add a mechanism for handling gethostname(2) in dhcpcd's privilege > separation code. IIRC gethostname() just reads /etc/hostname > 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. Samuel
