Linux kernel added system call--beginner ' s Guide

The Linux kernel sets up a set of subroutines that are used to implement system functions, called system calls. System calls are very similar to ordinary library function calls knowing that the system call is provided by the operating system core, running in a kernel mindset, while the normal function call is provided by the function library or the user itself, running in the user state. In general, a process cannot access the kernel, it cannot access the memory space that the kernel occupies, and cannot call kernel functions. This is known as protected mode. To interact with processes running on the user space, the kernel provides a set of interfaces. This interface application provides access to hardware devices and other operating system resources.

In fact, this set of interfaces is mainly to ensure the stability and reliability of the system, to avoid application arbitrary. The system call adds a middle tier between the user space and the hardware device, and also allows the user's application to not pipe the disk type and media, or even the file system that the file resides on. This facilitates portability of the application. System calls in Linux are the only means of user space access to the kernel, except for exceptions and interrupts.

In general, applications are programmed through the application interface API rather than directly through system tuning. Because this programming interface used by the application does not actually need to correspond to the system call one by one provided by the kernel. An API interface can be implemented as a system call, or it can be implemented by invoking multiple system calls, or without using any system calls. Programmers can deal directly with the API without regard to system calls.

System call: The kernel provides user-mode processes and interfaces for hardware devices for the services provided by the user process; Secure access to resources managed by the kernel and improve system security; Improve the portability of the program; Linux system calls all start with "Sys_" in the kernel, such as Sys_fork, Sys_exit.

This article takes the kernel version of 3.13.10 as an example to demonstrate the call of the Hello World class, first look at the system calls that need to compile the kernel

1. Add a custom system call function at the end of the #include<linux/linkage.h> file to add a header file to KERNEL/SYS.C: Sys_mycall

2. Add a custom system call number in ARCH/X86/SYSCALLS/SYSCALL_64.TBL (32-bit system to 32) (on my machine in order next is 314)

3. Add your own system call function declaration in Arch/x86/include/asm/syscalls.h

Asmlinkage long sys_mycall (int num);

4. Kernel compilation

Remember to add-j4 and so on to speed up (even if the second compilation does not clean up the original target file is also very time consuming (disk IO is time-intensive, solid-state drives should be fast)

5. Writing user-state test procedures

int main () {printf ("The Return value is:%d.\n", Syscall (314,1234567)); return 0;}

Compile to Test_hello

6. Testing

You can update the kernel, modify the system's startup items, and so on. You can also use virtual machines for testing, which are tested using QEMU below (simple and powerful, you can specify the kernel and file system to boot)

You can download qemu from the source under Ubuntu, with the next linux-0.2 (wget wiki.qemu.org/download/linux-0.2.img)

Then put the Test_hello into the test system, perhaps you want to directly in the test system to compile the Test_hello directly, if you do not have a ready-to-use compiler test system, you can use BusyBox to compile a root file system

The following is a rough step (but does not include a compilation tool and a link library):

Make Menuconfig in the build options build BusyBox as a static binary (no shared libs) ensures that no dependencies are generated on the shared library.

Execute make Config_prefix=your/dir install will be installed into the development directory, such as rootfs/

DD If=/dev/zero of=rootfs.img bs=10240k count=1

Mkfs-t ext3 rootfs.img

sudo mount-t ext3-o loop rootfs.img rootfs

Copy BusyBox to rootfs.img and compile your test program to a static (gcc-static) copy to Rootfs.img

$ CD Rootfs
$ sudo mkdir dev
Create a common device (Mknod for character or block related files):
$sudo CD Dev
$ sudo mknod tty0 C 4 0
$ sudo mknod tty1 C 4 1
$ sudo mknod tty2 C 4 2
$ sudo mknod tty3 C 4 3
$ sudo mknod console C 5 1
$ sudo mknod null C 1 1
To create an init startup script
/etc/inittab file
$ sudo mkdir etc
$ CD etc/
$ sudo vim inittab
#This is the first script to run when startup
:: Sysinit:/etc/rc.d/rc.sysinit
:: Restart:/sbin/init
:: Ctrlaltdel:/sbin/reboot
:: Shutdown:/bin/umount-a–r
$ sudo mkdir rc.d
$ CD rc.d/
$ sudo vim rc.sysinit
Add the following content:
#!/bin/sh
MOUNT-T proc None/proc
Mount-t Sysfs None/sys
/bin/sh
$ sudo chmod a+x rc.sysinit
$ CD. /.. /.. /
Root filesystem complete, umount Rootfs
$ sudo umount rootfs.img

Ready to start with the root file system running kernel
Qemu-system-x86_64-hda rootfs.img-kernel/boot/vmlinuz-3.13.10--append ROOT=/DEV/SDA m=256 (see your case using a different command)
You can see that Linux is running on the quem (just start may need to enter to display the command prompt, if the file system is read-only available Mount-o Rw,remount/re-mount, if the startup prompts Init and other files can not be executed is you do not give it executable permissions. Executes the call_static in the test program (the full path is required for execution).

Linux kernel added system call--beginner ' s Guide