On 2023-08-09 04:58, Taylor R Campbell wrote:
>> Date: Tue, 8 Aug 2023 11:47:17 -0400
>> From: Theodore Preduta
>>
>> 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)
