From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2968 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Difficulty emulating F_DUPFD_CLOEXEC Date: Sat, 23 Mar 2013 22:17:07 -0400 Message-ID: <20130324021707.GB20323@brightrain.aerifal.cx> References: <20130324015923.GA5905@brightrain.aerifal.cx> <514E6082.4070104@eservices.virginia.edu> 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 1364091437 10431 80.91.229.3 (24 Mar 2013 02:17:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Mar 2013 02:17:17 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2969-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 24 03:17:44 2013 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 1UJaVD-0004Dr-W6 for gllmg-musl@plane.gmane.org; Sun, 24 Mar 2013 03:17:44 +0100 Original-Received: (qmail 30189 invoked by uid 550); 24 Mar 2013 02:17:19 -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 30180 invoked from network); 24 Mar 2013 02:17:19 -0000 Content-Disposition: inline In-Reply-To: <514E6082.4070104@eservices.virginia.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2968 Archived-At: On Sat, Mar 23, 2013 at 10:10:10PM -0400, Zvi Gilboa wrote: > >This uglifies fcntl.c a bit more, but I think it works. Does the above > >reasoning make sense? Any other ideas? > > In the hope that this matches the project's spirit... how about > running these tests during the build, and have a script (or a simple > test program) #define whether the target architecture supports > F_DUPFD_CLOEXEC or not? Potentially, this test could be added at > the very end of alltypes.h.sh It's not a matter of the architecture. It's a matter of the kernel version. F_DUPFD_CLOEXEC was not available until late in the 2.6 series, and musl aims to "mostly work" even with early 2.6, and to "partly work" (at least for single-threaded programs that don't use modern features) even on 2.4. For dynamic linking, it could make sense to have a slimmer version of libc.so that only supports up-to-date kernels, but for static linking, it's really frustrating to have binaries that break on older kernels, even if it is the broken kernel's fault. If the lack of these features were just breaking _apps_ that use them, it would be one thing, but several of the very-new atomic close-on-exec interfaces needed internally in musl for some core functionality -- things like dns lookups, popen, system, etc. Thus failure to emulate them when the kernel doesn't have working versions could badly break even "simple" apps that would otherwise be expected to work even on old kernels. Rich