From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4914 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: __xmknod, __sysv_signal Date: Fri, 18 Apr 2014 22:52:04 -0400 Message-ID: <20140419025204.GS26358@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1397875946 21505 80.91.229.3 (19 Apr 2014 02:52:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Apr 2014 02:52:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4918-gllmg-musl=m.gmane.org@lists.openwall.com Sat Apr 19 04:52:19 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WbLO6-0004de-04 for gllmg-musl@plane.gmane.org; Sat, 19 Apr 2014 04:52:18 +0200 Original-Received: (qmail 19473 invoked by uid 550); 19 Apr 2014 02:52:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 19465 invoked from network); 19 Apr 2014 02:52:17 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:4914 Archived-At: On Fri, Apr 18, 2014 at 09:18:33PM -0500, M Farkas-Dyck wrote: > A dynamic-linked binary blob I have wants these. Are these appropriate > to include in musl? I have a patch ready. Send the patch and I'll review it. For __xmknod, I think this is just the ABI symbol glibc uses for mknod, and we could certainly add it (though I question whether there are any useful programs using it that couldn't just be rebuilt against musl). For __sysv_signal, I'm not sure what we should do. Its semantics are different from signal(), but it's doubtful that any program actually intended to request the sysv semantics (they're fundamentally broken and have race conditions that renders any program using them buggy) so it might just make more sense to have it be an alias for signal than to actually implement the broken sysv behavior. (Most likely is that glibc's weird behavior with certain feature test macros caused a program to inadvertently pull in the broken sysv version of signal rather than the default one.) Rich