On Sun, Aug 28, 2022 at 11:03 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Sun, Jun 26, 2022 at 11:18 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > > On Tue, May 17, 2022 at 3:31 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > > > On Mon, May 16, 2022 at 3:45 PM Japin Li <japi...@hotmail.com> wrote: > > > > Maybe use the __illumos__ macro more accurity. > > > > > > > > +#elif defined(WAIT_USE_EPOLL) && defined(HAVE_SYS_SIGNALFD_H) && \ > > > > + !defined(__sun__) > > > > > > Thanks, updated, and with a new commit message. > > > > Pushed to master and REL_14_STABLE. > > FTR: I noticed that https://www.illumos.org/issues/13700 had been > marked fixed, so I asked if we should remove our check[1]. Nope, > another issue was opened at https://www.illumos.org/issues/14892, > which I'll keep an eye on. It seems we're pretty good at hitting > poll/event-related kernel bugs in various OSes.
I happened to notice in the release notes for OmniOS that Stephen posted in the nearby GSSAPI thread that this has now been fixed. I think there's no point in changing the back branches (hard to synchronise with kernel upgrades), but I also don't want to leave this weird wart in the code forever. Shall we remove it in 16? I don't personally care if it's 16 or 17, but I wanted to make a note about the cleanup opportunity either way, and will add this to the open commitfest.
0001-Trust-signalfd-on-illumos-again.patch
Description: Binary data
