From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Mon Jul 28 2008 - 11:30:38 PDT
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
pieces.
-Paul
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