Date: Fri, 22 Jan 2010 08:22:21 -0800 From: Randall Stewart <rrs@lakerest.net> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Greetings... a patch I would like your comments on... Message-ID: <CED4A5C6-4253-417B-AF10-1BC11CF10DA9@lakerest.net> In-Reply-To: <hjcib3$80r$1@ger.gmane.org> 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> <hjcib3$80r$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 22, 2010, at 8:04 AM, Ivan Voras wrote: > 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"? Yep.. has I am just sitting down to write my "super crusher" test case I realize .. what was I smoking when I said EVFILT_KQUEUE.. thats got to change.. I think maybe EVFILT_UMTX_COND is best.. UMTX might let you think you could send in a lock or something else.. > > You said you didn't make the actual connection to the userland > pthead_* API yet - how did you test it? Actually I am using just raw umtx itself. For just quick testing a _thr_umtx_wake((u_long *)addr, count); Works.. Or one can even dig in and do the actual syscall.. _umtx_op().. but that requires a lot more arguments ;-) I need to think on integrating it into pthread*.. but we actully have at work our own mutex stuff for apps that is in user space and is a bit faster (quite a bit)... and it uses the umtx stuff directly ;-) R > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > " > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CED4A5C6-4253-417B-AF10-1BC11CF10DA9>