Re: epoll exposure

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

On Fri, 11 Aug 2023 18:52:41 -0000 (UTC)
christos%astron.com@localhost (Christos Zoulas) wrote:

> In article <ZMihOin2SWeuO5Y5%homeworld.netbsd.org@localhost>,
> nia  <nia%NetBSD.org@localhost> wrote:
> >On Mon, Jul 31, 2023 at 07:18:38PM -0700, Jason Thorpe wrote:
> >> Anyway, like I said, I think the best way forward is to make it
> >possible for kq descriptors to be inherited? it?s a little tricky
> >because of some of the wacky stuff kqueue can track, but I think NetBSD
> >can lead on this and define a set of semantics that makes sense.
> >
> >Can we agree on renaming the header to sys/epoll_compat.h?
> 
> I see that you removed with without further discussion which is not the
> way we do things on NetBSD. Do you have an example where the epoll emulation
> breaks, because either forking matters or the implementation is
> incorrect/different?

Some examples of packages where forking _could_ have implications and
are not even possible to audit due to undefined number of downstream
consumers, some possibly outside of pkgsrc:

python, libevent, apr, libev

> I would agree on principle that it is better to use kqueue on BSD systems,
> but if it is not broken, why not advertise it?

pkgsrc had a lots of issues with epoll getting picked up on Illumos and
don't want to add more patches to deal with exceptions.

I see your point but I also don't see the point of rushing this
feature in by default and leaving pkgsrc developers and users to
deal with potential fallout, knowing there are rough corner cases.

If it can be agreed that we put back the header under a different name
that would be great.

-Tobias