Re: epoll exposure

[Greg Troxel <gdt%lexort.com@localhost>]

Jonathan Perkin <jperkin%pkgsrc.org@localhost> writes:

> * On 2023-08-13 at 18:10 BST, Tobias Nygren wrote:
>
>>On Sat, 12 Aug 2023 19:21:06 -0400
>>Christos Zoulas <christos%zoulas.com@localhost> wrote:
>>
>>> I really want to understand what's going on here (why do we think that
>>> our epoll implementation is broken in a way that will affect applications).
>>
>>jperkin@ might be able to explain what the issues with Illumos are,
>>but I guess the problems are of different nature than the NetBSD case.
>
> The problem is third-party software assumes epoll == Linux, and once

I see it that Linux was first with epoll and thus is the specification.
In an ideal world, it would have gone through POSIX, but whatever.
Once that exists, I think an epoll implementation in other operating
systems has to have the exact same semantics, or it's asking for
trouble, perhaps hard-to-find ways.

I don't really find it problematic that the world has assigned the word
epoll to Linux's implementation.  To object to that one has to object to
any non-POSIX feature in any OS.

> our epoll implementation landed to support LX binaries, a bunch of
> packages that previously built natively broke.

Is that because while it appeared to offer the same API, it did not
exactly?

> In hindsight we would have not shipped sys/epoll.h, it provides no
> benefits, and obviously it's preferable to use native features (event
> ports in our case, kqueue in yours).

Was your epoll intended to be Linux compatible, or something else?  It
would seem that if so, it should be exactly compatible, and if not it
should just have a different name.  It really feels like you have gone
down the path we are on, so your experience seems useful.

> So now I'm stuck with shipping a faked-up epoll.h in my build chroots
> that #error out forever, and still have to patch up some software that
> finds it and continues on regardless thinking we're Linux.
>
> Just Say No.

Do you mean:

  do not implement epoll in NetBSD native at all?

or

  if you implement epoll, it needs to be 100% compatible with Linux
  semantics so that programs that use it will work as one expects?


There are some programs out there that support epoll but not kqueue;
guile-fibers used to be one but grew kqueue support.