On 2023-07-31 21:25, Rin Okuyama wrote: > (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 <n...@netbsd.org> wrote: >> >>> On Mon, Jul 31, 2023 at 04:27:32AM -0700, Jason Thorpe wrote: >>>> >>>>> On Jul 31, 2023, at 1:38 AM, nia <n...@netbsd.org> 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.
The epoll implementation is literally a direct port of the one from FreeBSD's Linux compatibility layer, and so has the same limitations. > Is is still useful for real Linux applications? Or do you have a > plan to lift this limitation? As for if it is still useful, yes! I've tested a bunch of Linux binaries (admittedly mostly ones written in Go) and they all worked as expected. So from what I can tell, the fork() limitation is not that big of a deal in practice. Theo(dore)
