Re: epoll exposure

[Tobias Nygren <tnn%NetBSD.org@localhost>]

On Mon, 31 Jul 2023 08:38:31 +0000
nia <nia%NetBSD.org@localhost> wrote:

> Hey, I regret that epoll was committed without further discussion with
> pkgsrc developers. We have a lot of experience with this already
> (illumos/SmartOS exposes a compatibility epoll) and the situation is
> not entirely great and requires lots of workarounds.
> 
> Mostly, the situation of having epoll freely usable in public headers
> but discouraged in the man pages doesn't really work. Either we have
> barriers against its use, or we encourage its use.
> 
> Software is mostly tested on Linux and FreeBSD, which have either epoll
> or kqueue. Build systems will detect epoll and use it. Autotools is
> falling out of favour, so it is getting harder and harder to override
> the detection of operating system functions.  Build systems need to be
> patched.
> 
> I don't want pkgsrc to be full of "don't use epoll on NetBSD" workaronds.
> 
> I think the compatibility support should be opt-in.

The problem is even if we hide this under a feature test macro, some
build systems only check for existence of the <sys/epoll.h> header, so
we will still end up patching some packages unless we rename the header
also. And the workarounds will be mostly the same as those for Illumos
so we can't get rid of them either.

If the software supports kqueue(2) we obviously want to do that,
and I think we should tell the respective upstreams to default
to that on NetBSD so that we don't have to patch things.

But what if the alternatives are select(2) or epoll(2)?
Is/will the implementation be mature enough to replace select(2) or
is this only ever intended for software that only supports epoll(2)?

-Tobias