Movatterモバイル変換

How System Calls Work on Linux/i86

This section covers first the mechanisms provided by the 386for handling system calls, and then shows how Linux uses thosemechanisms. This is not a reference to the individual systemcalls: There are very many of them, new ones are addedoccasionally, and they are documented in man pages that shouldbe on your Linux system.

What Does the 386 Provide?

The 386 recognizes two event classes: exceptions andinterrupts. Both cause a forced context switch to new aprocedure or task. Interrupts can occur at unexpected timesduring the execution of a program and are used to respond tosignals from hardware. Exceptions are caused by the executionof instructions.

Two sources of interrupts are recognized by the 386:Maskable interrupts and Nonmaskable interrupts. Two sources ofexceptions are recognized by the 386: Processor detectedexceptions and programmed exceptions.

Each interrupt or exception has a number, which is referredto by the 386 literature as the vector. The NMI interrupt andthe processor detected exceptions have been assigned vectors inthe range 0 through 31, inclusive. The vectors for maskableinterrupts are determined by the hardware. External interruptcontrollers put the vector on the bus during theinterrupt-acknowledge cycle. Any vector in the range 32through 255, inclusive, can be used for maskable interrupts orprogrammed exceptions. Here is a listing of all the possibleinterrupts and exceptions:

The priority of simultaneous interrupts and exceptions is:

How Linux Uses Interrupts and Exceptions

Under Linux the execution of a system call is invoked by amaskable interrupt orexception class transfer, causedby the instructionint 0x80. We use vector 0x80 totransfer control to the kernel. This interrupt vector isinitialized during system startup, along with other importantvectors like the system clock vector.

iBCS2 requries anlcall 0,7 instruction, whichLinux can send to the iBCS2 compatibility module appropriate ifan iBCS2-compliant binary is being executed. In fact, Linuxwill assume that an iBCS2-compliant binary is being executed ifanlcall 0,7 call is executed, and will automaticallyswitch modes.

As of version 0.99.2 of Linux, there are 116 system calls.Documentation for these can be found in the man (2) pages. Whena user invokes a system call, execution flow is as follows:

• Each call is vectored through a stub in libc. Each callwithin the libc library is generally asyscallX() macro, whereX isthe number of parameters used by the actual routine. Somesystem calls are more complex then others because of variablelength argument lists, but even these complex system calls mustuse the same entry point: they just have more parameter setupoverhead. Examples of a complex system call includeopen() andioctl().
• Each syscall macro expands to an assembly routine whichsets up the calling stack frame and calls_system_call() through an interrupt, via theinstructionint $0x80

  For example, the setuid system call is coded as
  _syscall1(int,setuid,uid_t,uid);
  which will expand to:

  _setuid:  subl $4,%exp  pushl %ebx  movzwl 12(%esp),%eax  movl %eax,4(%esp)  movl $23,%eax  movl 4(%esp),%ebx  int $0x80  movl %eax,%edx  testl %edx,%edx  jge L2  negl %edx  movl %edx,_errno  movl $-1,%eax  popl %ebx  addl $4,%esp  retL2:  movl %edx,%eax  popl %ebx  addl $4,%esp  ret

  The macro definition for thesyscallX() macroscan be found in /usr/include/linux/unistd.h, and the user-spacesystem call library code can be found in /usr/src/libc/syscall/
• At this point no system code for the call has beenexecuted. Not until theint $0x80 is executed does thecall transfer to the kernel entry point_system_call(). This entry point is the same for allsystem calls. It is responsible for saving all registers,checking to make sure a valid system call was invoked and thenultimately transfering control to the actual system call codevia the offsets in the_sys_call_table. It is alsoresponsible for calling_ret_from_sys_call() when thesystem call has been completed, but before returning to userspace.

  Actual code forsystem_call entry point can be foundin /usr/src/linux/kernel/sys_call.S Actual code for many of thesystem calls can be found in /usr/src/linux/kernel/sys.c, andthe rest are found elsewhere.find is your friend.

• After the system call has executed,_ret_from_sys_call() is called. It checks to see ifthe scheduler should be run, and if so, calls it.
• Upon return from the system call, thesyscallX() macro code checks for a negativereturn value, and if there is one, puts a positive copy of thereturn value in the global variable_errno, so that itcan be accessed by code likeperror().

How Linux Initializes the system call vectors

Thestartup_32() code found in/usr/src/linux/boot/head.S starts everything off by callingsetup_idt(). This routine sets up an IDT (InterruptDescriptor Table) with 256 entries. No interrupt entry pointsare actually loaded by this routine, as that is done only afterpaging has been enabled and the kernel has been moved to0xC0000000. An IDT has 256 entries, each 4 bytes long, for atotal of 1024 bytes.Whenstart_kernel() (found in /usr/src/linux/init/main.c) iscalled it invokestrap_init() (found in/usr/src/linux/kernel/traps.c).trap_init() sets up the IDT viathe macroset_trap_gate() (found in /usr/include/asm/system.h).trap_init() initializes the interrupt descriptor table as shownhere:

How to Add Your Own System Calls

1. Create a directory under the /usr/src/linux/ directory to holdyour code.
2. Put any include files in /usr/include/sys/ and /usr/include/linux/.
3. Add the relocatable module produced by the link of your newkernel code to theARCHIVES and the subdirectory totheSUBDIRS lines of the top level Makefile. Seefs/Makefile, target fs.o for an example.
4. Add a#define __NR_xx to unistd.h to assigna call number for your system call, wherexx,the index, is something descriptive relating to your systemcall. It will be used to set up the vector throughsys_call_table to invoke you code.
5. Add an entry point for your system call to thesys_call_table in sys.h. It should match the index(xx) that you assigned in the previous step.TheNR_syscalls variable will be recalculatedautomatically.
6. Modify any kernel code in kernel/fs/mm/, etc. to take intoaccount the environment needed to support your new code.
7. Run make from the top level to produce the new kernelincorporating your new code.

Copyright (C) 1993, 1996 Michael K. Johnson, johnsonm@redhat.com.
Copyright (C) 1993 Stanley Scalsky

Messages

4.wrong file for system_call code by Tim Bird

3.would be nice to explain syscall macros by Tim Bird

2.wrong file for syscallX() macro by Tim Bird

1.the directory /usr/src/libc/syscall/ byvijay gupta

1....no longer exists. byMichael K. Johnson

->the solution to the problem by Vijay Gupta