Messages in this thread | | | Date | Mon, 18 Jan 1999 16:44:01 -0600 | From | Andy Glew <> | Subject | Re: 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/
| |