how to add syscall on x86_64

There is little documentation about how to add a system call to Linux kernel on x86_64. This is how I do it.

Of course adding new system call is hardly a good idea. But my teacher simply gives us the homework ;-)

Things are different now in these aspects:

1. Entry.S no longer contains the syscall table; those tutorial mentioning entry.S don't apply to 2.6.

2. Now the i386 and x86_64 arch are merged into one: x86. (See arch and include directories.) However, some files, like syscall_table_32.S, don't have corresponding ones under x86_64.

For i386, here's a list of files to be edited, (see this tldp page):

1. arch/i386/kernel/syscall_table.S,
(now arch/x86/kernel/syscall_table_32.S)
2. include/asm-i386/unistd.h,
(now include/asm-x86/unistd_32.h)
3. include/linux/syscalls.h

For x86_64 arch, no corresponding syscall_table_64.S exists. To add new system calls to x86_64 kernel, edit these files:

1. include/asm-x86/unistd_64.h,

Add lines like:

#define __NR_my_call 288
__SYSCALL(__NR_my_call, sys_my_call)

2. include/linux/syscalls.h
Add a declaration here:

asmlinkage long sys_my_call(int n);

Of course, you can write the implementation in kernel/sys.c or another new foo.c file and then write Makefiles.

Thanks to this thread.

cannot login to X after installing custom kernel

For the OS homework, I compiled a kernel and installed it.

1. On booting into an old kernel (not my newly compiled one), the login window (partly) showed up. And after inputting the password, what I got was a blank screen..

The problem here is that the root partition became full after installing the kernel.

So I tried to remove something. I deleted the /tmp directory.

2. Then on next boot, I got a popup window, "There is a problem with the configuration server. (/usr/libexec/gconf-sanity-check-2 exited with status 256)

The problem here is that, a new /tmp has been automatically created, which has the default permission (rwxr-xr-x). Changing it to 777 will get the work done :) Cheers.

BarCamp is cool!

I went to BarCamp today. Good place (in Intel's office), good topics and  good speakers (having enough open source contributors means good to me ;-). We had another discussion on open source community within colleges, from which I learned much about organizing a club like our Beihang Open Source Club.

Unfortunately, I had to go to another engagement and so missed most topics on BarCamp.

This another event is our freedesktop group in the College Open Source Society. I got an extremely important point: many times, the reason we study some specific technique is not we want to learn it, but that we want to solve some interesting problems, which happen to require this technique. The driving factor here is the problems.

It is because we want to make our desktop cool that we decide to learn GTK. Rather than, because GTK is so much fun that we want to learn it.