On Sun, 2007-02-25 at 17:33 +0200, Tzahi Fadida wrote: > On Sunday 25 February 2007 17:21, Avishay Traeger wrote: > > On Sun, 2007-02-25 at 14:32 +0100, Fernando Apesteguía wrote: > > > On 2/25/07, Liran <liransgarage@xxxxxxxxx> wrote: > > > > Avishay Traeger <atraeger <at> cs.sunysb.edu> writes: > > > > > Does it need to be in the kernel? A couple user space options are: > > > > > - use ptrace, but that has some limitations (you can only trace child > > > > > processes). > > > > > - use LD_PRELOAD > > > > > > > > > > To do it from the kernel, you can create a module that: > > > > > - on loading, replaces the existing system call pointers to functions > > > > > that collect the desired data and calls the original functions. > > > > > - on unloading, restores the original system call pointers. > > > > > > > > I will examine the LD_PRELOAD idea, seems like it could work. > > > > Regarding the kernel module idea by replacing an existing function, > > > > doing some stuff and then restoring the original system call - is > > > > this a normal way of approaching it? Would it be considered ok? > > > > > > No. It is dirty and unsafe in SMP systems. If you want to do that use > > > kprobes. > > > > Yes, you are correct - kprobes would be a much better way to do it. > > Is it not possible that kprobe (or rather jprobe) will be problematic since i > think it uses some kind of interrupt which might seriously degrade > performance to a point of unrealistic conditions? It will definitely slow down performance, but I think it is better than modifying the system call table. Doing this is racy, architecture-dependent, and you can run into problems if you have more than one module modifying the table. It is also very unsafe, and won't work with the kernels of all Linux distributions. If this is just some stupid project, and you don't care about issues such as these (you should), then you can export the syscall table and do whatever you wish with it. If you google on how to do this, you will find a lot of information. Avishay -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
