[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130324021707.GB20323@brightrain.aerifal.cx>
Date: Sat, 23 Mar 2013 22:17:07 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Difficulty emulating F_DUPFD_CLOEXEC
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
