Re: epoll exposure

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

(theo and christos added to cc:)

On 2023/07/31 23:04, Tobias Nygren wrote:
> On Mon, 31 Jul 2023 12:05:21 +0000
> nia <nia%NetBSD.org@localhost> wrote:
>
> > On Mon, Jul 31, 2023 at 04:27:32AM -0700, Jason Thorpe wrote:
> > > > On Jul 31, 2023, at 1:38 AM, 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.
> > >
> > > What?s even worse ? I think our epoll() emulation isn?t 100% compatible w/ Linux?s.  It wouldn?t bother me so much if it were, but I?m pretty sure it?s not.
> > >
> > > (IIRC, epoll descriptors are inherited across fork, and if ours is emulated with kqueue under the covers, then that can?t work?)
>
> Then I'm in favor of renaming the header until such time we feel the
> interface is 100% compatible.

epoll(2) for COMPAT_LINUX is implemented in as similar manner to
NetBSD's. Therefore, it should also have this compatible issue.
Is is still useful for real Linux applications? Or do you have a
plan to lift this limitation?

Thanks,
rin