>> It also is a wrong way to build self-configuration; such a test is
>> vulnerable to both false positives and false negatives. It should
>> be reported upstream as a bug. Much righter is to test whether
>> epoll, if present, produces the behaviour the program expects in the
>> uses it makes of
> It also is a wrong way to build self-configuration; such a test is
> vulnerable to both false positives and false negatives. It should be
> reported upstream as a bug. Much righter is to test whether epoll, if
> present, produces the behaviour the program expects in the uses it
> makes of it.
>>> The problem is third-party software assumes epoll == Linux,
>> Software that makes stupid assumptions will never go away.
>> Is it better to work around it (not ship epoll.h), or to get it
>> fixed (report it upstream as the bug it is)? I could argue that
>> either way.
> I don't really
On Mon, Aug 14, 2023 at 07:39:11AM -0400, Greg Troxel wrote:
> Jonathan Perkin writes:
>
> > * On 2023-08-13 at 18:10 BST, Tobias Nygren wrote:
> >
> >>On Sat, 12 Aug 2023 19:21:06 -0400
> >>Christos Zoulas wrote:
> >>
> >>> I really want to understand what's going on here (why do we think that
Mouse writes:
>> The problem is third-party software assumes epoll == Linux,
>
> Software that makes stupid assumptions will never go away.
>
> Is it better to work around it (not ship epoll.h), or to get it fixed
> (report it upstream as the bug it is)? I could argue that either way.
I don't
Jonathan Perkin writes:
> * On 2023-08-13 at 18:10 BST, Tobias Nygren wrote:
>
>>On Sat, 12 Aug 2023 19:21:06 -0400
>>Christos Zoulas wrote:
>>
>>> 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
> The problem is third-party software assumes epoll == Linux,
Software that makes stupid assumptions will never go away.
Is it better to work around it (not ship epoll.h), or to get it fixed
(report it upstream as the bug it is)? I could argue that either way.
/~\ The ASCII
* On 2023-08-13 at 18:10 BST, Tobias Nygren wrote:
On Sat, 12 Aug 2023 19:21:06 -0400
Christos Zoulas wrote:
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).
jperkin@ might be able to explain
On Sun, 13 Aug 2023 19:10:32 +0200
Tobias Nygren wrote:
> A similar situation arises with daemons that reload their configuration
> via the classic SIGHUP + fork(2) mechanism. If that is done from within
> the event loop I guess we lose?
Same goes of course for any trivial server process that
On Sat, 12 Aug 2023 19:21:06 -0400
Christos Zoulas wrote:
> 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).
jperkin@ might be able to explain what the issues with Illumos are,
but I guess the
> Date: Sat, 12 Aug 2023 19:21:06 -0400
> From: Christos Zoulas
>
> 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
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
nia writes:
> On Fri, Aug 11, 2023 at 06:52:41PM -, 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
On Fri, Aug 11, 2023 at 06:52:41PM -, 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
>
> On Aug 11, 2023, at 3:09 PM, Tobias Nygren wrote:
>
> On Fri, 11 Aug 2023 18:52:41 - (UTC)
> chris...@astron.com (Christos Zoulas) wrote:
>
>> In article ,
>> nia wrote:
>>> On Mon, Jul 31, 2023 at 07:18:38PM -0700, Jason Thorpe wrote:
Anyway, like I said, I think the best way
On Fri, 11 Aug 2023 18:52:41 - (UTC)
chris...@astron.com (Christos Zoulas) wrote:
> In article ,
> nia wrote:
> >On Mon, Jul 31, 2023 at 07:18:38PM -0700, Jason Thorpe wrote:
> >> Anyway, like I said, I think the best way forward is to make it
> >possible for kq descriptors to be inherited?
In article ,
nia wrote:
>On Mon, Jul 31, 2023 at 07:18:38PM -0700, Jason Thorpe wrote:
>> Anyway, like I said, I think the best way forward is to make it
>possible for kq descriptors to be inherited⦠itâs a little tricky
>because of some of the wacky stuff kqueue can track, but I think
On Mon, Jul 31, 2023 at 07:18:38PM -0700, Jason Thorpe wrote:
> Anyway, like I said, I think the best way forward is to make it possible for
> kq descriptors to be inherited… it’s a little tricky because of some of the
> wacky stuff kqueue can track, but I think NetBSD can lead on this and
> On Jul 31, 2023, at 6:53 PM, Theodore Preduta wrote:
>>
>> epoll(2) for COMPAT_LINUX is implemented in as similar manner to
>> NetBSD's. Therefore, it should also have this compatible issue.
>
> The epoll implementation is literally a direct port of the one from
> FreeBSD's Linux
On 2023-07-31 21:25, Rin Okuyama wrote:
> (theo and christos added to cc:)
>
> On 2023/07/31 23:04, Tobias Nygren wrote:
>> On Mon, 31 Jul 2023 12:05:21 +
>> nia wrote:
>>
>>> On Mon, Jul 31, 2023 at 04:27:32AM -0700, Jason Thorpe wrote:
> On Jul 31, 2023, at 1:38 AM, nia wrote:
> On Jul 31, 2023, at 6:25 PM, Rin Okuyama wrote:
>
> epoll(2) for COMPAT_LINUX is implemented in as similar manner to
> NetBSD's. Therefore, it should also have this compatible issue.
> Is is still useful for real Linux applications? Or do you have a
> plan to lift this limitation?
When I
(theo and christos added to cc:)
On 2023/07/31 23:04, Tobias Nygren wrote:
On Mon, 31 Jul 2023 12:05:21 +
nia wrote:
On Mon, Jul 31, 2023 at 04:27:32AM -0700, Jason Thorpe wrote:
On Jul 31, 2023, at 1:38 AM, nia wrote:
Hey, I regret that epoll was committed without further
On Mon, 31 Jul 2023 12:05:21 +
nia wrote:
> On Mon, Jul 31, 2023 at 04:27:32AM -0700, Jason Thorpe wrote:
> >
> > > On Jul 31, 2023, at 1:38 AM, nia wrote:
> > >
> > > Hey, I regret that epoll was committed without further discussion with
> > > pkgsrc developers. We have a lot of
On Mon, Jul 31, 2023 at 04:27:32AM -0700, Jason Thorpe wrote:
>
> > On Jul 31, 2023, at 1:38 AM, nia wrote:
> >
> > Hey, I regret that epoll was committed without further discussion with
> > pkgsrc developers. We have a lot of experience with this already
> > (illumos/SmartOS exposes a
> On Jul 31, 2023, at 1:38 AM, nia wrote:
>
> Hey, I regret that epoll was committed without further discussion with
> pkgsrc developers. We have a lot of experience with this already
> (illumos/SmartOS exposes a compatibility epoll) and the situation is
> not entirely great and requires lots
On Mon, Jul 31, 2023 at 11:27:37AM +0200, Tobias Nygren wrote:
> On Mon, 31 Jul 2023 08:38:31 +
> nia wrote:
>
> > Hey, I regret that epoll was committed without further discussion with
> > pkgsrc developers. We have a lot of experience with this already
> > (illumos/SmartOS exposes a
On Mon, 31 Jul 2023 08:38:31 +
nia wrote:
> Hey, I regret that epoll was committed without further discussion with
> pkgsrc developers. We have a lot of experience with this already
> (illumos/SmartOS exposes a compatibility epoll) and the situation is
> not entirely great and requires lots
27 matches
Mail list logo
