1. This was committed to HEAD and not to a release branch. HEAD
is supposed to contain some experimental features so that we can verify
that things work correctly. Now that it has been backed out, we'll never know.
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?
3. We discussed adding epoll as a native syscall in tech-kern and there were
no objections. 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.
I really want to understand what's going on here (why do we think that
our epoll implementation is broken in a way that will affect applications).
Best,
christos
> On Aug 12, 2023, at 6:58 PM, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> 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.
Attachment:
signature.asc
Description: Message signed with OpenPGP