Messages in this thread | | | Date | Tue, 19 Jan 1999 11:43:13 -0600 | From | Andy Glew <> | Subject | Re: Adding checkpointing API to Linux kernel |
| |
Urgghhh.... So maybe I have gone full circle. If you want to do transparent migration and checkpointing of statically linked binaries, then you need to intercept system calls.
An "interposition device driver" is a fairly nice and easy thing to do here - e.g. one that invokes arbitrary added code when a system call is done. This code might be: in the kernel (gack); in a separate process, when it really amounts to "debug breakpoint on trap", where it will be too slow for many applications, but fast enough for some (such as the simulations I run); or perhaps using code/data memory added to the original program as transparently as possible.
This is a special case of intercepting an arbitrary API. It is not as general. But it is more universally reliable than the binary editting approach. It will work with just about any binary, including statically linked binaries, and binaries that do wierd things like dynamically writing code to invoke system calls - e.g. it might allow transparent checkpointing and migration of things like a Java VM with JIT compilation. Such completeness is good.
I apologize to Werner, for having said that such interposition should not be in the kernel. My excuse is that I keep looking for that "single point of leverage". In this case, it appears that there are three main points of leverage: (1) a kernel syscall interposition layer, (2) jump table editting, and (3) binary editting. All have their respective advantages and disadvantages. None is uniformly more powerful than the other.
So, back to where we started: is there a kernel syscall interposition driver for LINUX? Another respondent implied that there might be.
- 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/
| |