[lkml]   [1999]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Adding checkpointing API to Linux kernel
Andy Glew wrote:
> By the way, although I do not know how to do this "API interposition"
> as flexibly on LINUX as on NT (I hope that Alan Cox will show me how),
> I would probably agree with someone who said that this is not an appropriate
> topic for the kernel group.

I think he is suggesting modifying LD_LIBRARY_PATH and placing a
dynamically linked .so library that would contain the intercepted calls
in a directory at the front of LD_LIBRARY_PATH.

I don't know if this would requiring re-compiling all of glibc with the
intercepted calls and then using that as a substitute. If that's not the
case, then this could essentially be done with ANY of the commercial
UNIXes that support LD_LIBRARY_PATH and its variants as well, including
SunOS, IRIX, etc. 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.)

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.

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), so I hope I wasn't
totally off track. Flames to /dev/null, please (and certainly not to
Andy in any event.)

> One of Windows' strengths has been that such interposition can be done
> for any API that is implemented in a DLL, not just the kernel/syscall
> interface. (There have been papers about syscall interposition for UNIXes
> that worked just on the syscall interface, not for any other.)
> Therefore, typically, in Windows a whole slew of different modules
> come together in the form of DLLs. Sometimes a module is implemented
> by something resembling an OS kernel or device driver - i.e. a shared
> library interface that is implemented in a different privilege domain.
> Sometimes a module is implemented by message passing or remote
> procedure call - marshalling its arguments and sending them to a different
> process, perhaps a different computer system. Sometimes a module is just
> an ordinary library.
> The nice thing about interposition is that you can intercept any such DLL
> level API. It's frequently used for profiling.
> Doing interposition just for the kernel would be insufficient, although it might
> answer the network batch programs' needs - such as Werber's for GNU QUEUE.
> There are any number of binary editting tools for UNIXes out there.
> Probably at least one of them runs on LINUX. Unfortunately, most
> of the ones I know are a bit too low level, but maybe not all are like that.
> So, therefore: I don't think that it is appropriate to add such an interposition API
> to the LINUX kernel. It is better done at a higher level - in the dynamic link
> tools, but also, perhaps, through binary editting on running programs.
> It should be noted that API editting is a very specific form of binary editting
> - if APIs are first class, and all calls go through interface tables, then
> it corresponds solely to changing the interface tables, and involves none
> of the complexities of actually editting the call sites (finding free registers,
> etc.)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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