Re: kevent ext member?

[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).

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