Date: Fri, 22 Jan 2010 17:04:56 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-hackers@freebsd.org Subject: Re: Greetings... a patch I would like your comments on... Message-ID: <hjcib3$80r$1@ger.gmane.org> In-Reply-To: <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> References: <AD99639C-0DC6-4C4C-B945-A8BD23D6DF8E@lakerest.net> <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> <hjcgfv$100$1@ger.gmane.org> <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hjcib3$80r$1>