diff mbox

RFC: soft-fp: Condition sfp-machine.h include path on __KERNEL__

Message ID alpine.DEB.2.10.1503062326580.9654@digraph.polyomino.org.uk
State New
Headers show

Commit Message

Joseph Myers March 6, 2015, 11:28 p.m. UTC 
My Linux kernel patch to update the kernel to current glibc soft-fp
<https://sourceware.org/ml/libc-alpha/2015-02/msg00107.html> still
leaves a few small differences between the two copies of soft-fp.

I think it's desirable to avoid such differences completely if
possible by having one set of sources suitable for use in both places.
To that end, this patch introduces a conditional on __KERNEL__ for the
path by which sfp-machine.h is included.

What do people think about the principle of including such
conditionals?  I think one will also be needed for zero-initialization
in _FP_DECL and _FP_FRAC_DECL_* (where Linux kernel functions may do
various operations with different sorts of unpacking and packing, so
it's not obvious to the compiler that the packing always only uses the
fields that were initialized, but the glibc and libgcc use of separate
functions for each operation avoids this issue).  For other
differences I hope to be able to avoid such conditionals.

Tested for powerpc-nofpu that installed stripped shared libraries are
unchanged by this patch.

2015-03-06  Joseph Myers  <joseph@codesourcery.com>

	* soft-fp/soft-fp.h [!_LIBC && __KERNEL__]: Include
	<asm/sfp-machine.h> instead of <sfp-machine.h>.

Comments

Roland McGrath March 7, 2015, 12:28 a.m. UTC | #1 
I think it's fine if it facilitates verbatim code-sharing.  It's not really
different from the kind of stuff we do in files that we want to share with
gnulib.  It wouldn't hurt to add some comments.
Mike Frysinger March 7, 2015, 8:10 p.m. UTC | #2 
On 06 Mar 2015 23:28, Joseph Myers wrote:
> What do people think about the principle of including such
> conditionals?  I think one will also be needed for zero-initialization
> in _FP_DECL and _FP_FRAC_DECL_* (where Linux kernel functions may do
> various operations with different sorts of unpacking and packing, so
> it's not obvious to the compiler that the packing always only uses the
> fields that were initialized, but the glibc and libgcc use of separate
> functions for each operation avoids this issue).  For other
> differences I hope to be able to avoid such conditionals.

makes sense to me
-mike
diff mbox

Patch

diff --git a/soft-fp/soft-fp.h b/soft-fp/soft-fp.h
index d0171e3..156048b 100644
--- a/soft-fp/soft-fp.h
+++ b/soft-fp/soft-fp.h
@@ -34,6 +34,8 @@ 
 
 #ifdef _LIBC
 # include <sfp-machine.h>
+#elif defined __KERNEL__
+# include <asm/sfp-machine.h>
 #else
 # include "sfp-machine.h"
 #endif