tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kevent ext member?



> 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?  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?


Home | Main Index | Thread Index | Old Index