Re: sparc implementation

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Mon Jul 28 2008 - 11:30:38 PDT

  • Next message: Vincentius Robby: "Re: sparc implementation"
    In both the BLCR kernel and user-space code we make use of atomic 
    counters for various purposes, including a reader-writer sort of lock in 
    the user space code.  In all architectures we've supported so far we've 
    had support for atomic operations on 32-bit integers.  However, on SPARC 
    revisions prior to "SPARC V8+" (UltraSPARC) the only support for atomics 
    is via spinlocks.  The spinlock approach can work in the kernel because 
    one can block interrupts.  In user-space, however, the spinlock approach 
    can lead to deadlock in the presence of signal handlers.  So, I believe 
    that it is either impossible or impractical to port BLCR to chips older 
    than UltraSPARC. (I am willing to be proven wrong, but am strongly 
    discouraging you from trying for older cpus as I think success is unlikely)
    Except for the atomic-ops issue above, I am not aware of a "major 
    hindrance" for a SPARC port of BLCR, but we don't have the resources 
    (either people time or machines) to do it ourselves.  For somebody with 
    understanding of the SPARC platform (including ASM and ABI issues), we 
    should be able to provide the guidance to perform a port.
    The "vmadump" directory contains support only for 2.4.X kernels, and is 
    being dropped from BLCR (kept only for RH9 and RHEL kernels in 
    blcr-0.7.X and will be removed entirely by the time 0.8.X is released).  
    The original BProc/VMADump code did support SPARC, though I have no idea 
    if that was well tested or not.  When BProc/VMADump was ported to the 
    2.6.X kernels, the SPARC platform code was apparently not ported.  This 
    was most likely due to a combination of lack of time and lack of interest.
    The steps for a BLCR port are:
    1) vmadump4/vmadump_<ARCH>.c, with additions to vmadump.h if needed.
        This should hopefully just be a straight-forward port of the older 
    vmadump code.  However, the 2.4.x vs. 2.6.x differences may be 
    non-trivial.  Additionally, BLCR supports pthreads, which the original 
    VMADump did not, and this requires that the ABI's thread-specific data 
    pointers be dealt wth properly, which the exisiting VMADump code might 
    not do.
    2) include/blcr_ksyms.h needs the right inline ASM bits for linker info
    3) cr_module/arch/<ARCH>/cr_arch.h needs a couple of inline functions 
    which can probably be found in the vmadump code.
    4) libcr/arch/<ARCH>/cr_{arch,atomic}.h needs inline ASM for system 
    calls and atomic operations, plus ASM for a simple signal handler.  All 
    these things should be present in glibc's source code somewhere.  DO NOT 
    cut-and-paste any of this stuff from the Linux kernel (the kernel is GPL 
    and the code in libcr is LGPL)
    Without knowing your own level if familiarity with the SPARC platform, I 
    cannot estimate the time this port would take.  However, I can say that 
    I will be available to provide some guidance with the various inline ASM 
    Vincentius Robby wrote:
    > Hello,
    > What is the major hindrance in porting BLCR to sparc? and does the 
    > vmadump component support sparc already? (it is listed in one of the 
    > comments in ./vmadump/ but I see no comment saying so in ./vmadump4/)
    > Thanks.
    Paul H. Hargrove                          PHHargrove_at_lbl_dot_gov
    Future Technologies Group                 
    HPC Research Department                   Tel: +1-510-495-2352
    Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900

  • Next message: Vincentius Robby: "Re: sparc implementation"