Re: epoll exposure

[Theodore Preduta <theo%pta.gg@localhost>]

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 <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.

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)