Re: List of System calls and corresponding kernel routines

[fche at redhat dot com (Frank Ch. Eigler)]

Hi -

Prasanna S Panchamukhi <prasanna@in.ibm.com> writes:

> As per Frank's suggestion, I have listed most of the system calls and
> corresponding kernel routine below. 

Thank you.

> Currently I am writting a kernel module using runtime to insert
> probes on system calls entry point and exit point.

You might want to focus only on problematic cases, where the system
call entry/exit point does not map exactly to function entry/exit
boundaries.  The default cases will not need any C-level assistance.


> Below are the set of system calls and corresponding kernel routines.
> If a user wants to trace time() system call, he needs to place a
> probe on sys_time() routine.

Right, most of these sound like a good fit for the "probe alias"
script-level construct.  This is not parsed yet at the moment, but
will be very shortly.


> [...]
> The example below shows the probe handler to trace fork()/clone()/vfork() 
> system call. Here the handler logs the function arguments.
> 
> global entry_time, my_clone_flags, my_stack_start, my_regs, my_stack_stize
> global my_parent_tidptr, my_child_tidptr, fork_times[MAX_SYSCALL]
> 
> probe kernel.syscall("fork") {
> 	thread->entry_time = $timestamp; 		# "macro" variable
> 	thread->my_clone_flags = $clone_flags; 		# function argument
> [...]

In this example scenario (an end-user probe, not a library tapset),
most of these variables are not used in another probe, and thus don't
need to be saved as globals.  Using probe aliases to *define*
kernel.syscall("fork") in terms of kernel.function("sys_fork"), one
can make these values cheap locals instead.


> [...]
> System call		: Corresponding kernel routine
> =-=-=-=-=-=-		 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> time			: sys_time
> stime			: sys_stime
> [...]

Nice list.  Would you mind creating a new directory "syscalls" under
src/tapsets, and archiving it there?  A more formal tapset template
could follow later.


- FChE