Re: epoll exposure

[Taylor R Campbell <campbell+netbsd-tech-userlevel%mumble.net@localhost>]

> Date: Sat, 12 Aug 2023 19:21:06 -0400
> From: Christos Zoulas <christos%zoulas.com@localhost>
> 
> 2. Nobody has given an example of an application that breaks, or answered
>     the question if we understand how the Illumos feature is breaking things,
>     or even if the Illumos implementation is similar to ours. Theodore mentioned
>     that aside from the fork issue, we should be fully compatible. Do we know
>     of any applications that open an epoll file descriptor and then fork? Was
>     that the reason the the Illumos implementation is failing?

I'm not sure and I'd be curious to hear more.  The illumos man page
details some semantic differences: <https://illumos.org/man/7/epoll>.
But I think the pkgsrc experience should definitely give us pause and
we should try to coordinate it, e.g. by doing bulk builds and testing
applications that we determine use epoll, rather than barge ahead and
assume pkgsrc developers will find and fix the fallout.

Backing out the change later, if we might decide to do that, is very
painful, and it's why we're still stuck with the awful getrandom(2)
API that I made the mistake of adopting back in 2020.  (Although if we
have to rebuild all netbsd-10 packages anyway for openssl3, maybe
now's our chance to ditch it...)

> 3. We discussed adding epoll as a native syscall in tech-kern and there were
>     no objections.

It was proposed on 2023-06-21 at
<https://mail-index.netbsd.org/tech-kern/2023/06/21/msg028927.html>.

The first reply within hours on 2023-06-21 at
<https://mail-index.netbsd.org/tech-kern/2023/06/21/msg028927.html>
asked why it is a good API to adopt, and whether for testing the
compat syscall we could add an emul_syscall so it doesn't get exposed
to applications.

The second reply within a week on 2023-06-25 at
<https://mail-index.netbsd.org/tech-kern/2023/06/25/msg028932.html>
asked that it be done in a way that can be used by ATF but will not be
detected by configure scripts.

I read both of these as objections.  No reply answering either of
these, and the commit went in in a way that is exposed to configure
scripts and not limited to the ATF tests.

I think it is fair for nia to find this frustrating: mixed feedback on
adopting the syscall, two objections with specific requests for how to
start, and it goes in in exactly the way that the objections objected
to.

>                    It is common courtesy to discuss reversions before taking
>     action, specially when things do not appear to be broken. It would have
>     taken a minute or so for Nia to write an email and one or two more days
>     with epoll(2) exposed would not have harmed anyone. I was under the
>     impression that the conversation was still going on.

The commit went in on Friday, 2023-07-28, and on Monday, 2023-07-31,
nia re-raised the same objection as before, with more detail:
<https://mail-index.netbsd.org/tech-userlevel/2023/07/31/msg014063.html>.

nia suggested a concrete alternative to enable testing (installing it
at sys/epoll_compat.h) on 2023-08-01:
<https://mail-index.netbsd.org/tech-userlevel/2023/08/11/msg014104.html>
and there was silence in the thread for another ten days, suggesting
the discussion was over and nia's objections were being ignored.

It is true that our rule is for reverts to go through discussion and
then core@ first, which this could be seen to violate.  But:

(a) nia did try to go through discussion by raising objections twice
    over the course of a month, with no response;
(b) this wasn't entirely a revert -- all the code is still there, just
    not exposed from libc; and
(c) I think a lot of people have gotten the impression that core@ is
    anemic and inattentive, and it's on us to dispel that impression
    by acting responsively and responsibly in the community, not just
    by asserting authority by insisting on the text of rules.

So, moving forward:

How about we prioritize implementing an emul_syscall or something so
we can automatically test compat_linux?

This will be a much bigger win, I think, than adopting epoll(2), and
if epoll(2) is really worth it (and I'm not sure it is; I'd like to
see a more compelling positive argument for adopting it) we can
separately coordinate that with pkgsrc resources.