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