On Fri, Feb 15, 2008 at 08:51:38AM -0800, Adam Litke wrote:
>
> As the next patch introduces code to implement a piece of the PowerPC 64-bit
> ELF ABI, and since that code is limited to the ppc64 architecture, a new
> mechanism is required (and supplied by this patch).
>
> Using architecture-specific routines will work as follows: Any code module
> that needs access to these routines will include "arch.h". This file is
> automatically generated by the build system and will contain a comment and one
> or two '#include' lines to include 1) an arch-specific header (if present) and
> 2) a generic header. The generic header provides default definitions for any
> functions that may not be defined by the arch-specific header.
>
> In this way, architectures can optionally supply custom functions without
> impacting other architectures and with minimal effect on code readability.
>
> Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
This seems overly complex infrastructure. We already have
arch-specific functions for the direct_syscall() thingy we use for
error messages while the program is unmapped. You should simply be
able to include the necessary code in another file listed with those
asm stubs in the Makefile.
The prototypes should be common across archs, so can be in a common
header file. And you can supply a "default" stub version in common
code, marked as a weak function.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
