On 01/22/10 16:55, Randall Stewart wrote:
If I read the comment at filt_umtxattach() correctly, in the best case
you would need an extension to the kevent structure to add more fields
like data & udata (for passing values back and forth between userland
and kernel). I agree with this - it would be very convenient for some
future purposes (like file modification notification) if the kernel
filter could both accept and return a struct of data from/to the
userland.
Yeah, more arguments inside the kevent would allow me to add the
COND_CV_WAIT* where a lock and condition are passed
in as well... But I was hesitant to add more than was already there
since doing
so would cause ABI ripples that I did not want to face.
Yes, this should be done carefully; just adding more "data" and "udata"
fields will postpone the problem to when someone else needs one more
field to make his idea working - a memory blob should probably be the
way to go.
I plan on committing this to head if I don't get strong "you idiot you
did it wrong" comments ;-)
Hmmm, something just occured to me: why did you name the event / filter
"EVFILT_KQUEUE"? Why not something like "EVFILT_UMTX" or "EVFLT_COND"?
You said you didn't make the actual connection to the userland pthead_*
API yet - how did you test it?
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
