Re: blcr: Support for more arches.

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Sun Aug 16 2009 - 13:16:28 PDT

  • Next message: Alan Woodland: "Re: blcr: Support for more arches."
    Alan et el.,
    Hello from BLCR's "upstream".
    I am pleased to hear that BLCR has been accepted in to Debian.  Since 
    you bring up the question of other arches, I'd like to provide a few 
    notes on the subject:
    1)  We are always happy to receive patches/code from the community, but 
    require a Developer's COO
    2)  Anybody wanting to work on an arch port of BLCR should contact us 
    for some guidance.  There are e-mails floating around out there that 
    almost constitute a "HOWTO", but they've not been organized into a 
    coherent guide yet.  Contacting us also serve to prevent duplicate 
    efforts (encourage collaboration over competition)
    3) We'd very much welcome anybody who wants to assemble a "BLCR Arch 
    port HOWTO" from the e-mails I mention above.
    4) General notes:
        + A new port of the vmadump code is the biggest piece of work and 
    requires non-trivial knowledge of architecture-specific aspects for the 
    Linux kernel implementation
        + Assuming a working knowledge of assembly for the target architecture:
           - The libcr/arch code is generally simple for anybody familiar 
    with the user-space ABI, including syscall convention
           - The cr_module/arch code is generally simple for anybody who 
    knows the kernel ABI for the given arch
    5) Notes on some of the specific architectures not yet supported:
        + ALPHA: There *is* a vmadump for the Alpha, but it has not been 
    tested with BLCR.  Since a quick inspection of 
    linux-2.6.30/arch/alpha/kernel does not appear to have a VDSO, there is 
    probably very little if any additional kernel-space work to be done for 
        + SPARC:  There is a partial implementation for SPARC already in 
    BLCR, contributed by Vincentius Robby <vincentius_at_umich_dot_edu> and Andrea 
    Pellegrini <apellegr_at_umich_dot_edu>.  Note that we need a user-space atomic 
    compare-and-swap, and IIRC that means that only UltraSPARC and newer are 
    ever likely to work.
       + IA64:  We've receive email in the past from somebody in China who 
    as apparently ported BLCR to IA64, but does not wish to distribute their 
    work (as IS permitted by GPL and LGPL).  However, the existence of their 
    effort is encouraging.
    Regarding the question of *BSD or Hurd (ignoring that "L" in BLCR stands 
    for Linux):
    While I don't want to totally rule-out the possibility, I doubt that 
    porting to another OS is an easy task.  Counting only arch-independent 
    code here are about 14,000 lines in cr_module and over 2,000 in 
    vmadump_common.c.  I can identify less than 1,500 of those lines as 
    doing something OS-independent; the rest is all dealing with Linux 
    kernel data structures.  So, to be honest I think if somebody were to 
    "port" BLCR to another OS they will have earned the right to name their 
    package something else if they want.
      I the interest of the least confusion among potential users, I do 
    think marking the package as arch-specific (i386, amd64, arm, ppc, 
    ppc64) and os-specific (linux) is the best practice.  Users who want 
    BLCR for unsupported arches will probably still ask "why is my arch not 
    supported?".  If/when a future release adds arches, then the 
    arch-specific list can expand, right?
    Alan Woodland wrote:
    > (For readers on checkpoint_at_lbl_dot_gov blcr was accepted into Debian last 
    > night)
    >> It seems that your package currently doesn't work on all arches.
    >> It fails with errors like:
    >> checking build system type... alphaev68-unknown-linux-gnu
    >> checking host system type... alphaev68-unknown-linux-gnu
    >> configure: error: Sorry, architecture alphaev68 is not supported
    >> at this time.
    > This is correct
    >> It seems that it atleast requires some porting work to add
    >> other arches, but I think it's actually not that much?
    > Mostly it's just vmadump that would need porting I think. It's pretty 
    > sensitive to layout of process related structs I think, as well as low 
    > level specifics like registers that are architecture dependent 
    > obviously. The source is well structured and tidy though so someone 
    > knowledgeable about the unsupported architectures should find it easy 
    > enough to patch I think. The relevant places are:
    > - vmadump4/
    > - libcr/arch/
    > - cr_module/arch/
    > I just noticed too that there is actually a alpha version of vmadump 
    > already there, so it's just libcr and cr_module that's missing for alpha.
    > I deliberately didn't mark it as amd64, i386, sparc, arm and ppc only 
    > in the hopes that someone with hardware, time and knowledge might 
    > contribute patches.
    >> It also looks like this is Linux specific?  Do you think
    >> this can work on kfreebsd or hurd?
    > Hmm, that's an interesting one. The user space bits do a pretty good 
    > job of insulating you from any/all kernel space mechanics that make 
    > the checkpointing possible. I guess that means in theory it would be 
    > possible to do quite sanely. I've got precisely no experience with any 
    > *bsd kernel space development, and my knowledge of hurd is almost the 
    > same too. Maybe it would have made sense to mark it as not for the 
    > non-linux ports though to save the buildds from trying every time.
    > I'm always interested in patches and I'm pretty sure upstream would be 
    > grateful also.
    > Alan
    Paul H. Hargrove                          PHHargrove_at_lbl_dot_gov
    Future Technologies Group                 Tel: +1-510-495-2352
    HPC Research Department                   Fax: +1-510-486-6900
    Lawrence Berkeley National Laboratory     

  • Next message: Alan Woodland: "Re: blcr: Support for more arches."