From: Ulisses (ra993482_at_ic.unicamp.br)
Date: Fri Feb 18 2005 - 15:02:05 PST
On Fri, 2005-02-18 at 11:05 -0800, Paul H. Hargrove wrote:
> You are receiving this message because you have e-mailed us in the past
> with questions about the development status of Berkeley Lab
> Checkpoint/Restart (BLCR) for Linux.
Thank you! :-)
> This release adds the experimental Linux 2.6.x support that many of you
> have asked me about. It is still only for ia32 (no Opteron yet, but I
> am working on it). The 2.6 support is much less tested than the 2.4
> kernel support. So, we'd really apreciate hearing of your success or
> failure with BLCR 0.4.0.
I've just tried to compile BLCR 0.4.0 on a Fedora Core 3 system running
kernel 2.6.10-1.766_FC3 and gcc 3.4.2. I downloaded the BLCR package,
unpacked it to /tmp and ran the configure:
$ ./configure --with-linux=/lib/modules/2.6.10-1.766_FC3/build --with-
system-map=/boot/System.map-2.6.10-1.766_FC3 --prefix=/tmp/blcr
Everything seemed ok, but when I tried to compile it by typing 'make',
I noticed some little problems:
- libcr won't be compiled unless the following patch is applied because
compilation ends up with this error from linux/include/config.h:
"#error including kernel header in userspace; use the glibc headers
instead!"
--- blcr-0.4.0/libcr/Makefile.am.orig 2005-02-18 19:49:36.676842325
-0200
+++ blcr-0.4.0/libcr/Makefile.am 2005-02-18 19:50:13.771503858
-0200
@@ -27,8 +27,7 @@
-D_REENTRANT\
-I$(top_builddir)/include\
-I$(top_srcdir)/include\
- -I$(srcdir)/arch/@CR_ARCH@/\
- -I@LINUX_SRC@/include
+ -I$(srcdir)/arch/@CR_ARCH@/
EXTRA_DIST=arch license.txt
dist-hook:
- gcc doesn't like the inlining of cr_barrier_init, cr_barrier_enter
and cr_barrier_break, but it doesn't stop the compilation process. It
says "cr_module/cr_barrier.h:57: sorry, unimplemented: inlining failed
in call to 'cr_barrier_break': function body not available" and when the
function is used "cr_module/kbuild/cr_chkpt_req.c:113: sorry,
unimplemented: called from here".
- the functions timeval_to_jiffies() and jiffies_to_timeval() already
exist in linux kernel 2.6 in linux/include/jiffies.h, so I guess the
following patches make sense.
--- blcr-0.4.0/configure.ac.orig 2005-02-18 15:21:35.000000000
-0200
+++ blcr-0.4.0/configure.ac 2005-02-18 20:30:02.448827538 -0200
@@ -436,7 +436,7 @@
## Now we check for specific kernel features...
-CR_CHECK_KERNEL_COMPILE([timeval_to_jiffies],[
+CR_CHECK_KERNEL_COMPILE([2.4 timeval_to_jiffies],[
#include <linux/time.h>
],[
#ifdef timeval_to_jiffies
@@ -445,10 +445,29 @@
int x = sizeof(&timeval_to_jiffies);
#endif
])
+CR_CHECK_KERNEL_COMPILE([2.6 timeval_to_jiffies],[
+ #include <linux/jiffies.h>
+ ],[
+ #ifdef timeval_to_jiffies
+ /* OK, it exists as a macro */
+ #else
+ int x = sizeof(&timeval_to_jiffies);
+ #endif
+ ])
# OK if missing
-CR_CHECK_KERNEL_COMPILE([jiffies_to_timeval],[
+
+CR_CHECK_KERNEL_COMPILE([2.4 jiffies_to_timeval],[
#include <linux/time.h>
- ],[
+ ],[
+ #ifdef jiffies_to_timeval
+ /* OK, it exists as a macro */
+ #else
+ int x = sizeof(&jiffies_to_timeval);
+ #endif
+ ])
+CR_CHECK_KERNEL_COMPILE([2.6 jiffies_to_timeval],[
+ #include <linux/jiffies.h>
+ ],[
#ifdef jiffies_to_timeval
/* OK, it exists as a macro */
#else
--- blcr-0.4.0/cr_module/cr_module.h.orig 2005-02-16
20:34:31.000000000 -0200
+++ blcr-0.4.0/cr_module/cr_module.h 2005-02-18 20:41:39.844646017
-0200
@@ -244,7 +244,7 @@
cr_rstrt_req_t *rstrt_req;
} cr_pdata_t;
-#if !HAVE_TIMEVAL_TO_JIFFIES
+#if !defined(HAVE_2_4_TIMEVAL_TO_JIFFIES) && !defined
(HAVE_2_6_TIMEVAL_TO_JIFFIES)
// Basic adaptation of timespec_to_jiffies from
include/linux/time.h
static __inline__ unsigned long
timeval_to_jiffies(struct timeval *value)
@@ -260,7 +260,7 @@
}
#endif
-#if !HAVE_JIFFIES_TO_TIMEVAL
+#if !defined(HAVE_2_4_JIFFIES_TO_TIMEVAL) && !defined
HAVE_2_6_JIFFIES_TO_TIMEVAL)
// Basic adaptation of jiffies_to_timeval from
include/linux/time.h
static __inline__ void
jiffies_to_timeval(unsigned long jiffies, struct timeval *value)
And I finally got stuck with TASK_ZOMBIE being used but it's defined
nowhere in linux kernel 2.6. The task_struct struct has the exit_state
member, that can be either EXIT_ZOMBIE or EXIT_DEAD. Maybe
cr_module/kbuild/cr_chkpt_req.c and cr_module/kbuild/cr_rstrt_req.c
should test for exit_state being EXIT_ZOMBIE?
Well, that's it.. I hope this feedback helps you guys (and I also hope
my e-mail client doesn't mess up all the pacthes). Keep up the nice
work. :-)
Best regards,
-- Ulisses