Re: epoll exposure

[Greg Troxel <gdt%lexort.com@localhost>]

nia <nia%NetBSD.org@localhost> writes:

> On Fri, Aug 11, 2023 at 06:52:41PM -0000, Christos Zoulas wrote:
>> I see that you removed with without further discussion which is not the
>> way we do things on NetBSD. Do you have an example where the epoll emulation
>> breaks, because either forking matters or the implementation is
>> incorrect/different?
>
> We maybe need some clarification there - it's come up before
> that changes should be backed out while the discussion is ongoing.
> I've generally complied and backed out my changes when someone
> wants to discuss them.

As someone who has given others a hard time about this I'd like to
strongly second what nia@ said.  I agree with and sympathize with the
idea that we don't randomly revert, but the total situation is more
subtle.

First, we have a norm that changes that others object to should be
proposed and discussed, and only if there is pretty strong rough
consensus or better that they get committed.  For weaker rough
consensus, I see it as a call for core or pmc.  A real problem is when
people just commit anyway, and people object.  The right thing is for
the committer to say "didn't realize this was so controversial" (often
it's hard to tell) and revert.  It can easily be an honest mistake to
not realize that other people will have issues with something.

I believe it is very important to have the discussion with the
controversial code not in tree, because that frames the argument as "I
would like to commit this, is that ok" rather than "someone else wants
to revert this thing that we already have".  In some sense that's the
same, but we are talking people and it's really clear to me that it is
not the same.

I view committing controversial things and not reverting them as a
bigger problem than someone else doing the revert after it has been
called for.  In my view core should be asking for things to be reverted
for discussion when they turn out to be controversial.

> Riastradh raised that having a symbol named "epoll_create" in libc
> may be enough to change the way build systems behave, so we need
> to be really careful here. In my opinion it's better to back out
> ABI changes that may be problematic early before we're stuck with
> something we might regret later.

Agreed.  In this case, the complaints were rapid and significant and it
was obviously tricky.

And, my read of the discussion was that adding an emulated epoll for
linux binaries was ok but adding native epoll had nowhere near reached
consensus.

>> I would agree on principle that it is better to use kqueue on BSD systems,
>> but if it is not broken, why not advertise it?
>
> We need to be 100% sure that this code will remain 100% compatible
> with Linux for the forceeable future. Exposing epoll involves
> compiling code that has only ever been tested on Linux on
> NetBSD for the first time, while avoiding tried and tested code.
>
> This is really scary, and can create all sorts of headaches in
> porting work, especially if the epoll-enabled source code uses
> all sorts of other Linuxisms.

Agreed.  Porting linuxy code is hard enough.  I think we need to talk
about exact semantics match, and if not to really have the rationale
super clear and widely accepted.   I think a  lot of people are just not
wanting to bite off that trouble.