In D31037#720058, @wulf wrote:

In D31037#717055, @vico13.chen_gmail.com wrote:

In D31037#711053, @wulf wrote:

Why do you store epoll events in separate member? kqueue(2) explicitly states that ext[0] and ext[1] fields are created for that:

ext        Extended data passed to and from kernel.  The ext[0] and
           ext[1] members use is defined by the filter.  If the filter
           does not use them, the members are copied unchanged.

You need to add new filter flag e.g. NOTE_EPOLL to indicate that your code starts using ext[0] to return event data in epoll format

It is OK to just use ext[0] for 'pevent' and 'pmask' (8 bytes). But my concern is: since ext[0] is a generic define, if other components also use ext[0], it will be conflict. Who use ext[0] must confirm no others use it. It is a potential risk.

Which conflict?

Two concerns:

1. In 'linux_epoll_ctl', we set ext[0], and it means, in furture, others can't re-use it, and they must use ext[1].

There are no 'others' in linux_epoll_ctl. Only epoll compat code uses these kevents

Got you. These kevents are registered in 'linux_epoll_ctl', and they are only used for linux epoll case. So we need a flag (NOTE_EPOLL) to indicate these kevent are for linux epoll. And in the socket filter read/write, we need check this flag (NOTE_EPOLL), and the assgin values to pevent. Am I right?

In D31037#711053, @wulf wrote:

Why do you store epoll events in separate member? kqueue(2) explicitly states that ext[0] and ext[1] fields are created for that:

ext        Extended data passed to and from kernel.  The ext[0] and
           ext[1] members use is defined by the filter.  If the filter
           does not use them, the members are copied unchanged.

You need to add new filter flag e.g. NOTE_EPOLL to indicate that your code starts using ext[0] to return event data in epoll format

It is OK to just use ext[0] for 'pevent' and 'pmask' (8 bytes). But my concern is: since ext[0] is a generic define, if other components also use ext[0], it will be conflict. Who use ext[0] must confirm no others use it. It is a potential risk.

Which conflict?

Two concerns:

1. In 'linux_epoll_ctl', we set ext[0], and it means, in furture, others can't re-use it, and they must use ext[1].
2. In 'linux_epoll_ctl', we set ext[0], and then the kevent is registered. Is there a risk that 'ext[0]' of this kevent is overrided by other components?

In D31037#709587, @wulf wrote:

In D31037#709379, @vico13.chen_gmail.com wrote:

wulf,
all works well, and we don't see it breaks the API and ABI. Could you please describe more details how it breaks the API and ABI?

if your pre-patch code uses ext[3] to store some bits of context in it, it can not be compiled and executed on post-patch system due to array out-of-bound access. This is an API breakage.
if your binary is compiled out of code which uses ext[0] to store some bits of context and it was built on pre-patch system, it can not run on post-patch system correctly anymore as ext[0] value is clobbered by pevents member which have the same offset. This is an ABI breakage.

Test cases

wulf,
This patch is applied in our project which is based on FreeBSD12, and all works well, and we don't see it breaks the API and ABI. Could you please describe more details how it breaks the API and ABI?
If there are concerns for eliminating of ext[3] array, how about just introducing pevent and pmask and keep ext[4] in 'struct kevent'?

1. Introduce 'pmask' in kevent to return the EPOLL events which are requested by applications.
2. Add a test case which is compiled on Linux.