This is the mail archive of the
mailing list for the glibc project.
glibc soft-fp ready for kernel use
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Cc: <davem at davemloft dot net>
- Date: Tue, 4 Nov 2014 16:47:06 +0000
- Subject: glibc soft-fp ready for kernel use
- Authentication-results: sourceware.org; auth=none
Updating the comparison of glibc and Linux kernel soft-fp versions from
<https://sourceware.org/ml/libc-alpha/2013-10/msg00345.html>, I think the
glibc code is now ready to replace the kernel version if anyone is
interested in making the relevant kernel changes (which would be fairly
substantial, given all the interface changes in soft-fp in the past ten
years or so, especially the conversion of various macros to use raw or
semi-raw values for speed).
Specifically, all the substantive features listed there from the kernel
version are now implemented in the glibc version, and the identified bug
fixes have equivalent fixes in the glibc version. The following are not
in the glibc version (the first two I start from an expectation that they
aren't needed any more, the last two I think it would be fine for the
glibc and kernel versions to remain different in those areas only):
* commit 40d3057ac036f2501c1930728a6179be4fca577b, "math-emu: Fix
compiler warnings". Actually, I suspect those warnings indicate a
bug in a macro other than the one changed, or in how kernel code is
using macros, so my default presumption is that this patch is not
appropriate and not needed with current soft-fp.
* Initializations in _FP_FRAC_DECL_* and _FP_DECL - as above, I think
these are inappropriate and could be covering up other bugs.
* Multiple-include guards on individual headers (added in the kernel,
or, in the case of soft-fp.h, the specific guard macros changed). I
think the op-*.h headers included by soft-fp.h should probably be
like bits/*.h in giving an error if not included from soft-fp.h, but
headers such as single.h might reasonably have such guards added,
even if the style in glibc would be different from in the kernel.
* Changes to paths by which headers include each other (maybe
appropriate conditionals on __KERNEL__ can be used to allow a single
version to be shared). If the only differences between the glibc
and kernel versions can be these last two items, that would be good
even if we can't completely unify the versions.
Joseph S. Myers