On Wed, Mar 19, 2014 at 7:10 PM, Jilles Tjoelker <jil...@stack.nl> 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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
