[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-tech-userlevel
Subject:    Re: epoll exposure
From:       Mouse <mouse () Rodents-Montreal ! ORG>
Date:       2023-08-16 19:37:35
Message-ID: 202308161937.PAA17443 () Stone ! Rodents-Montreal ! ORG
[Download RAW message or body]

>> 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.

> As Linux introduced epoll (or so I think) I think it's appropriate --
> absent a SUS specification -- to assume it works as under Linux?

Probably.  But that wasn't what was being suggested, at least not as I
read it.  Here's fuller context:

>>>>> 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 don't really see it as a bug.  You'd have to have all those
>>> problems have configure logic that says

>>>   if we find an epoll implementation, then we have a list of
>>>   operating systems that have implemented an epoll that has
>>>   different semantics and we have to reject it

>>> It seems far more reasonable to say that if an OS implements a
>>> different epoll, then it should call it something else.

>> [...]  It also is a wrong way to build self-configuration; [...]

What I was arguing is not "NetBSD should have epoll with different
semantics" but "the problematic programs would have to have a configure
test with a blacklist of OS/version pairs".  Blacklisting by OS/version
is what I was arguing against.

> How would you argue if some other OS was to introduce something
> called kqueue with semantics different from FreeBSD?

I would still say that a configure test that blacklisted them by
OS/version is a broken test.  I say it should either blindly assume the
semantics it expects or it should test for the semantics it cares
about, depending on the philosophy stance its authors prefer.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
[prev in list] [next in list] [prev in thread] [next in thread]