> Date: Sat, 12 Aug 2023 19:21:06 -0400 > From: Christos Zoulas <chris...@zoulas.com> > > 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.
