Re: epoll exposure

[Jason Thorpe <thorpej%me.com@localhost>]

> On Jul 31, 2023, at 6:53 PM, Theodore Preduta <theo%pta.gg@localhost> wrote:
>> 
>> 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.

I want to make clear — I’m not trying to knock on the work that’s been done here… in fact, kudos to you, Theo, for doing this!

I only wanted to raise the concern about it as a *native* call… If it’s exposed natively, application developers might expect it to behave the same way, including the inherit-across-fork thing… I think if there’s a minor glitch in emulation, it’s a little easier to shrug off.  When I did timerfd and eventfd, I made sure the behavioral differences between the native NetBSD implementation and Linux were limited to things that didn’t make sense on NetBSD anyway, and would only be noticed by things that are elbow-deep in weird Linux-specific sh*t for other reasons :-)

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.

-- thorpej