Comment 99 for bug 804943

Revision history for this message
Joni-Pekka Kurronen (joni-kurronen) wrote :

https://upc-bugs.lbl.gov/blcr/doc/html/BLCR_Admin_Guide.html

Berkeley Lab Checkpoint/Restart (BLCR) Administrator's Guide
This guide describes how to install, configure, and maintain Berkeley Lab Checkpoint/Restart (BLCR) for Linux. For usage instructions please see the companion BLCR User's Guide.
1. System Requirements
BLCR consists of two kernel modules, some user-level libraries, and several command-line executables. No kernel patching is required.

BLCR has been engineered to work with a wide range of Linux kernels:

    Many major vendor distributions of Linux. Those tested historically have include SuSE 9.x and OpenSuSE 10.0 though 11.0, CentOS 3.1, and Fedora Core 2 through 10 (Note: this list is NOT exclusive).
    Many "vanilla" Linux 2.6.x kernels (from kernel.org) have also been tested with many glibc versions (2.2 through 2.9).
    We believe vanilla versions 2.6.0 through 2.6.38 all work.
    BLCR uses a set of autoconf-based feature tests to probe the kernels it builds against. It is thus likely that a custom kernel based on one of the above kernel sources will work with BLCR, provided that patches applied to the kernel don't invalidate assumptions BLCR has made.

BLCR uses assembly code to save some program state (most notably the CPU registers). This means that the BLCR kernel modules are not portable across CPU architectures "out of the box". BLCR has long supported the x86 and x86_64 architectures. The 0.6.0 release was the first to include experimental support for PowerPC64 and for ARM, while the 0.7.0 release added experimental support for 32-bit PowerPC. Currently x86 and x86_64 systems are the most fully tested with BLCR, with the other architectures tested heavily only at release time. Porting BLCR to a different CPU is not a large software effort if one has sufficient Linux kernel experience and knowledge of the target CPU's ABI and instructions. Please contact us if you are interested in contributing a port. We are especially interested in somebody with the time and equipment to complete the unfinished port to SPARC64.