On Wed, Jun 21, 2023 at 01:50:47PM -0400, Theodore Preduta wrote:
> 2. They can be used to test the epoll code with ATF.
In my opinion we should expose such system calls in a way that they
can be used by ATF but won't be detected by configure scripts.
Mouse writes:
>> It is definitely a real problem that people write linuxy code that
>> seems unaware of POSIX and portability.
>
> While I feel a bit uncomfortable appearing to defend the practice (and,
> to be sure, it definitely can be a problem) - but, it's also one of the
> ways advancements
> It is definitely a real problem that people write linuxy code that
> seems unaware of POSIX and portability.
While I feel a bit uncomfortable appearing to defend the practice (and,
to be sure, it definitely can be a problem) - but, it's also one of the
ways advancements happen: add an
Martin Husemann writes:
> On Wed, Jun 21, 2023 at 01:50:47PM -0400, Theodore Preduta wrote:
>> There are two main benefits to adding native epoll syscalls:
>>
>> 1. They can be used to help port Linux software to NetBSD.
>
> Well, syscall numbers are cheap and plenty...
>
> The real question
On Wed, Jun 21, 2023 at 01:50:47PM -0400, Theodore Preduta wrote:
> There are two main benefits to adding native epoll syscalls:
>
> 1. They can be used to help port Linux software to NetBSD.
Well, syscall numbers are cheap and plenty...
The real question is: is it a usefull and consistent API
While implementing Linux's epoll syscalls in compat_linux for my GSoC
project, my mentor and I had the idea to also add native NetBSD entry
points for epoll. After some back and forth, we thought it would be
good to solicit opinions from the rest of the community.
There are two main benefits to
