From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Sun Aug 16 2009 - 13:16:28 PDT
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
Alpha.
+ 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.
Alan,
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?
-Paul
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