From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 22 16:05:20 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72B851065733 for ; Fri, 22 Jan 2010 16:05:19 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B2E7D8FC21 for ; Fri, 22 Jan 2010 16:05:18 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NYM0Z-00034U-RV for freebsd-hackers@freebsd.org; Fri, 22 Jan 2010 17:05:15 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jan 2010 17:05:15 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jan 2010 17:05:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Fri, 22 Jan 2010 17:04:56 +0100 Lines: 29 Message-ID: References: <9bbcef731001220527u5bbec479n59143b6631c6e2d8@mail.gmail.com> <20100122151035.GX77705@hoeg.nl> <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.5) Gecko/20100118 Thunderbird/3.0 In-Reply-To: <905EFCFB-7362-4F54-B9E7-69C0B4699A37@lakerest.net> Sender: news Subject: Re: Greetings... a patch I would like your comments on... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 16:05:20 -0000 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?