From owner-svn-src-head@FreeBSD.ORG Wed Mar 19 19:57:03 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 987BB369; Wed, 19 Mar 2014 19:57:03 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB92C6C4; Wed, 19 Mar 2014 19:57:02 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u56so7253859wes.23 for ; Wed, 19 Mar 2014 12:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jHvQEbrprj623o50YvLYxUPWbTC4fmNDb6+881rSr+4=; b=i5OFA2nXfnoNzMdv7wr9uNVjViVJ8jvbbOEPLGcVa900gNGp/sWBRD4ncDx3YJBFkK 4vlrTSFlkzNhAjMIE1GPW6xgP4Wu+TlGLrH6EhFnkRZHZQpUG9Vll0wHjaTAiMZNF0ie Dk9INADI8WCQA0EynBt0mPTKltAg8Mj4+9GTZE5MN44xmLexYIXX7uS0EysJthYai4kb sul0I3TUroz1CnQMYp5tXG60Q6RBeX0lbqdSEtz0UmyozPrFIfK8vMZ/E0Ed/pKjMc0c 2LTbQj/6/c1/KpLWZY6mTSrPenfnpKE9fJhlBphTBirrYbcH9EQPSltu4pdd+WY36Ugc OBEw== MIME-Version: 1.0 X-Received: by 10.180.12.233 with SMTP id b9mr21273120wic.8.1395259021296; Wed, 19 Mar 2014 12:57:01 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.217.61.196 with HTTP; Wed, 19 Mar 2014 12:57:01 -0700 (PDT) In-Reply-To: <20140319181051.GA86549@stack.nl> References: <201403182132.s2ILW33e060898@svn.freebsd.org> <20140319181051.GA86549@stack.nl> Date: Wed, 19 Mar 2014 20:57:01 +0100 X-Google-Sender-Auth: gclyKRDbcgcTV9wzWtSNeBE8QN4 Message-ID: Subject: Re: svn commit: r263318 - in head: sys/compat/freebsd32 sys/kern sys/sys usr.bin/truss From: Attilio Rao To: Jilles Tjoelker Content-Type: text/plain; charset=UTF-8 Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 19:57:03 -0000 On Wed, Mar 19, 2014 at 7:10 PM, Jilles Tjoelker wrote: > On Tue, Mar 18, 2014 at 09:32:03PM +0000, Attilio Rao wrote: >> Author: attilio >> Date: Tue Mar 18 21:32:03 2014 >> New Revision: 263318 >> URL: http://svnweb.freebsd.org/changeset/base/263318 > >> Log: >> Remove dead code from umtx support: >> - Retire long time unused (basically always unused) sys__umtx_lock() >> and sys__umtx_unlock() syscalls >> - struct umtx and their supporting definitions >> - UMUTEX_ERROR_CHECK flag >> - Retire UMTX_OP_LOCK/UMTX_OP_UNLOCK from _umtx_op() syscall > >> __FreeBSD_version is not bumped yet because it is expected that further >> breakages to the umtx interface will follow up in the next days. >> However there will be a final bump when necessary. > >> Sponsored by: EMC / Isilon storage division >> Reviewed by: jhb > >> [snip] >> Modified: head/sys/sys/umtx.h >> ============================================================================== >> --- head/sys/sys/umtx.h Tue Mar 18 20:14:13 2014 (r263317) >> +++ head/sys/sys/umtx.h Tue Mar 18 21:32:03 2014 (r263318) >> [snip] >> -static __inline int >> -umtx_wait(u_long *p, long val, const struct timespec *timeout) >> -{ >> - if (_umtx_op(p, UMTX_OP_WAIT, val, 0, >> - __DECONST(void *, timeout)) == -1) >> - return (errno); >> - return (0); >> -} >> - >> -/* Wake threads waiting on a user address. */ >> -static __inline int >> -umtx_wake(u_long *p, int nr_wakeup) >> -{ >> - if (_umtx_op(p, UMTX_OP_WAKE, nr_wakeup, 0, 0) == -1) >> - return (errno); >> - return (0); >> -} >> - > > These two do not use struct umtx, are not obsolete and are used by some > ports, such as lang/sbcl with certain options. They are similar to the > Linux futex system call. The relatively recent libxshmfence uses the > underlying umtx_op directly, mainly because there is no static inline > function for UMTX_OP_WAIT_UINT. They can just use _umtx_op() straight off. I already mentioned in the commit message that I will bump __FreeBSD_version appropriately when more API breakage will be introduced and we will have a relatively "stable" API situation of umtx. At that point ports maintainer can fix the ports. Attilio -- Peace can only be achieved by understanding - A. Einstein