lkml.org 
[lkml]   [1999]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Adding checkpointing API to Linux kernel
> Which raises the question of why hasn't it been done
> by the Condor group? (Why are they trying to _edit_ binaries to get this
> to work.)

(1) It may be unfair to say that the Condor group is doing the binary
editing. I saw a student class project presentation that was doing so.

(2) Binary editing allows you to intercept (a) statically linked binaries
(as long as you have symbol table information) and (b) already running
programs. So, for example, you could start up a SAS or SPSS job
interactively, realize that it is going to take too long, go away for
lunch, realize that it still hasn't finished, and then say "install the
system call interception and checkpointing library, and go and migrate
yourself off onto the network somewhere".


> The advantage of GNU/Linux in this sense is that it uses glibc, so the
> source is available and its much easier to create an intercept library
> like this, but it wouldn't be impossible for the commercial Unixes.

Source code certainly helps. However, not having source code forces
you to make modularity decisions that are sometimes better.

> If it's not an appropriate topic for the kernel group, please accept my
> apologies for starting the thread. It's sometimes hard to figure out
> whether something is best done in libc or in the kernel. We are talking
> about intercepting kernel calls and it would be done in the kernel under
> NT (which does just about everything in the kernel)

Actually, on Windows this sort of thing is not done in the kernel,
but in a totally different process - essentially in a debugger process,
which dynamically installs code in the user process to accomplish it.

The question is not "whether something is best done in libc or in the kernel".
The question is whether it is better done in still a different module.



> Flames to /dev/null, please (and certainly not to Andy in any event.)

Sorry for the splurge on this mailing list.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.078 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site