Date: Mon, 17 Apr 2017 16:24:07 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 218571] umtx compat6 regression affecting 'jar' command Message-ID: <bug-218571-8-w2595G6jJh@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-218571-8@https.bugs.freebsd.org/bugzilla/> References: <bug-218571-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218571 Jilles Tjoelker <jilles@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jilles@FreeBSD.org Assignee|freebsd-bugs@FreeBSD.org |freebsd-threads@FreeBSD.org Hardware|amd64 |Any --- Comment #4 from Jilles Tjoelker <jilles@FreeBSD.org> --- Most of the time, freebsd6 compatibility is left in. It seems inconsistent = to remove the old umtx calls if the rest is left in. It does look unfortunate to have two copies of almost-but-not-completely duplicate code added to kern_umtx.c. However, it may be the least bad way so that development of the current code is hindered as little as possible. Adding the syscall stubs and exports back to libc seems unnecessary since t= hese calls were not supposed to be used by applications directly, and mixing libc/libthr versions is not supported. Likewise, what was removed from <sys/umtx.h> need not be restored (except as needed for kernel implementati= on). UMUTEX_ERROR_CHECK was added after stable/6 and never used, so need not be restored either. If the old code is dynamically linked, it is worth a try to run it with the= new libc and libthr. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-218571-8-w2595G6jJh>