Re: epoll exposure

[nia <nia%NetBSD.org@localhost>]

On Mon, Jul 31, 2023 at 11:27:37AM +0200, Tobias Nygren wrote:
> 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

We can easily introduce a feature to pkgsrc that will cause the header
to be automatically exposed for software that opts-in. We already
do this for packages that expect ncurses. If FAKE_NCURSES is set,
an artificial ncurses.h will be created in the build directory.
If ALLOW_COMPAT_EPOLL is set, we could rename epoll_compat.h to
epoll.h.

NetBSD supports _much more_ Linux-centric software than illumos does.