Re: kevent ext member?
> Date: Wed, 9 Aug 2023 13:11:13 -0400 > From: Theodore Preduta > > On 2023-08-09 04:58, Taylor R Campbell wrote: > >> Date: Tue, 8 Aug 2023 11:47:17 -0400 > >> From: Theodore Preduta > >> > >> 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. Cool, thanks! Seems like kind of poor API design but not one we have much control over if we want kqueue to remain compatible with FreeBSD and macOS, which is generally good.
Re: kevent ext member?
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)
Re: kevent ext member?
> 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? Do we have any upcoming uses of filters that would use the extra members? > > 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?
Re: kevent ext member?
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). > 1. Who owns it? Does it depend on the filter, the identifier, or >both? Depends on the filter(?). It's stored on the knote (same as udata). > 2. Who writes or reads it, inside the kernel? It doesn't seem to be >mentioned in kern_event.c. It's copied implicitly when the kevent gets added to the knote, ie. kern_event.c:1977 n->kn_kevent = *kev; in kqueue_register and kern_event.c:2450 *kevp = kn->kn_kevent; in kqueue_scan. Although, now that I'm looking at it again, I think there might be a bug with how it's copied in. Specifically, udata can be modified with another call to kevent(), but the same is not true for ext. > 5. What happens if I fill nonzero ext[0]/ext[1] in a userland call to >kevent? What filters respect it and how do I find out, short of >reading the code? > > 6. What do I get if I read out of it in a userland call to kevent? >What filters fill it and how do I find out, short of reading the >code? My understanding of the description of the ext field is that also says "if the filter does not mention the ext field, it does not use it" (so all of the fields should just be copied unchanged), but I guess that should be written explicitly. > 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. Theo(dore)
kevent ext member?
What is the new struct kevent::ext member about? I read the new man page but I'm still unclear on it. 1. Who owns it? Does it depend on the filter, the identifier, or both? 2. Who writes or reads it, inside the kernel? It doesn't seem to be mentioned in kern_event.c. 3. Why is ext[0]/ext[1] treated differently from ext[2]/ext[3]? 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? 5. What happens if I fill nonzero ext[0]/ext[1] in a userland call to kevent? What filters respect it and how do I find out, short of reading the code? 6. What do I get if I read out of it in a userland call to kevent? What filters fill it and how do I find out, short of reading the code? 7. What's an example of a use from userland? Why did we need to change the kevent syscall? 8. Is this API shared with any other BSDs, or is anyone proposing to share it, or is it now a unique NetBSD extension?
