Re: kevent ext member?

[Theodore Preduta <theo%pta.gg@localhost>]

On 2023-08-09 04:58, Taylor R Campbell wrote:
>> Date: Tue, 8 Aug 2023 11:47:17 -0400
>> From: Theodore Preduta <theo%pta.gg@localhost>
>>
>> On 2023-08-08 06:53, Taylor R Campbell wrote:
>>> What is the new struct kevent::ext member about?  I read the new man
>>> page but I'm still unclear on it.
>>> 8. Is this API shared with any other BSDs, or is anyone proposing to
>>>    share it, or is it now a unique NetBSD extension?
>>
>> This comes from FreeBSD, which takes it from MacOS's kevent64_s.
>>
>>> 4. If ext[2]/ext[3] are passed through verbatim, how are they
>>>    different from just a larger udata member?  Why can't the user
>>>    application just use a pointer to a larger buffer here?
>>> 3. Why is ext[0]/ext[1] treated differently from ext[2]/ext[3]?
>>
>> The semantics come from MacOS (and are the same in FreeBSD).
> 
> OK, thanks!  What do they use it for?

MacOS uses it for their EVFILT_MACHPORT (which is EVFILT_READ but for
MacOS's IPC primitive) to return a pointer to the received message,
which I doubt can be ported.

I don't think that FreeBSD currently makes use of it outside of Linux
epoll compat.

> Do we have any upcoming uses of
> filters that would use the extra members?

I don't think so.

>>> 7. What's an example of a use from userland?  Why did we need to
>>>    change the kevent syscall?
>>
>> Because epoll makes use of it.  There isn't really a good other place to
>> put the epoll_event::data member, given its semantics.
> 
> OK, so is the only current user the kernel side of the epoll code?

Yes.

Theo(dore)