tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: epoll exposure
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.
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.
> 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.
Home |
Main Index |
Thread Index |
Old Index