Irfan’s Corner on the Web On Mac, Linux, Grid, Virtualization and Software Technology

Adding a System call (linux 2.4.x)

1. About This Document

This document explains a way to add a system call to linux kernel catered to the linux 2.4.x series. It is based on the guide by Worcester Polytechnic Institute available at here. The guide is for linux 2.2.x, some changes where to the cotents to make it a guide for linux 2.4.x. The reference kernel in this guide is linux 2.4.31

A system call is the standard way an OS service is exported to a user program. For example, to provide users a new semaphore like synchronization method, some system calls need to be provided to access it. Likewise, a system call may be used to give users access to internal information of a file system such as superblock or inodes. The following description is based on linux kernel version 2.2.14 on i386 machine architecture. Also, it is assumed that readers are familiar with Building Linux Kernel.

2. Preparing for A New System Call

A system call cannot be called directly from a user process. Instead, they are called indirectly via an interrupt and looked up in an interrupt table. Thus, when you define a new system call you insert a new entry in this table. You do this by editing the file linux/arch/i386/kernel/entry.S. Inside, you should see lines like:


.data
ENTRY(sys_call_table)
.long SYMBOL_NAME(sys_ni_syscall) /* 0 - old "setup()" system call*/
.long SYMBOL_NAME(sys_exit)
.long SYMBOL_NAME(sys_fork)
.long SYMBOL_NAME(sys_read)
.long SYMBOL_NAME(sys_write)
..
..
.long SYMBOL_NAME(sys_ni_syscall) /* sys_set_tid_address* /


After the "sys_ni_syscall" line, add your entries for your new system calls, with the words "sys_" prepended. For example, you might add the following line for your new system call "myservice":


.long SYMBOL_NAME(sys_myservice) /*259 */

You also need to generate a system call "stub" so that an ordinary user program can invoke your system call. You do this by editing the file linux/include/asm/unistd.h (In linux sources) where you will find lines like:


#define __NR_exit 1
#define __NR_fork 2
...
#define __NR_exit_group 252


You should add #defines for your new system calls at the end, with the prefix "__NR_" in front of it. For example, you might add the line:


#define __NR_myservice 259

3. Places for Your System Call Source Files

After inserting your new system call entry in the interrupt table and preparing a stub for it, you will need to define (or implement) the system call. It will be easiest to have the system call definitions in your own source code files, say myservice.h and myservice.c.

In general, header files for machine architecture independent system calls and functions are kept under linux/include/linux/ and machine architecture dependent ones are kept in linux/include/asm/. Therefore, it would be a good idea to follow this convention. For example, the header file for the system calls for your new synchronization method, of which the implementation is machine architecture specific, would be placed in linux/include/asm/, while the header file for your machine architecture independent system call that access the superblock of one or more of your file systems would be placed under linux/include/linux.

The place for actual implementation file (myservice.c in this example) could vary. For example, if you are implementing a new process synchronization method, linux/ipc/ would be the best place for it. If you are implementing a file system related one, linux/fs/ would be the best place.

Remember that you will need to modify the Makefile in the directory you placed your .c file so that your code gets compiled and linked in properly. Modify the Makefile line to have a .o of your source code. For example, adding myservice.o in linux-2.4.31/mm/


obj-y := memory.o mmap.o filemap.o mprotect.o mlock.o mremap.o vmalloc.o slab.o bootmem.o swap.o vmscan.o page_io.o page_alloc.o swap_state.o swapfile.o numa.o oom_kill.o shmem.o myservice.o

The rest of the Makefiles can remain untouched (Makefile changes will be similar if you choose to add your code elsewhere).

4. System Call Source File Basics

In order to be linked properly, your system calls need the word "asmlinkage" prepended to their function header and "sys_" prepended to the name. For example, you would have:


asmlinkage int sys_myservice(int arg1, char* arg2) {
/* implementation of myservice */
}


Also, you will have to have #include so the compiler will recognize the word "asmlinkage".

Lastly, the user "stub" can be automatically generated so that a user program can use your system call. There are some macros defined for this in . The format is "_syscallN(return type, function name, arg1 type, arg1 name ...)" where "N" is the number of parameters. For example, you might have the line:


_syscall2(int, myservice, int, arg1, char*, arg2);

to generate the stub (in this case, the 2 is for 2 arguments). Note, that your call to generate the stub (as above) should be put it in your header file for users(myservice-user.h). Also, you need to #include in myservice-user.h to make this work. A user program could then just call myservice() as they do other system calls.

Here is an example myservice.h, myservice.c, myservice-user.h and user-app.c assuming myservice.h is under linux/include/linux/ and myservice-user.h is under /usr/include/sys/

myservice.h (used within kernel only) #ifndef __LINUX_MYSERVICE_H#define __LINUX_MYSERVICE_H#include #endif

myservice.c (system call implementation) include asmlinkage int sys_myservice (int arg1, char* arg2) {printk("My Service Called"); return(1); }

myservice-user.h (for user application) #include #include_syscall2(int, myservice, int, arg1, char*, arg2);

user-app.c (user application) #include main() {myservice(1, "hi");