then wakes up the process blocking in flush_scheduled_tasks, context_task_done

wait_queue, trying to flush_out queued tasks,before blocking again by calling

schedule and waiting for the schedule_task routine to wake it up.Task Queues and

Bottom Halves would be taken up after System Calls.

System Call Handling :

arch/i386/kernel/entry.S: system_call is the entry point of System Calls.:

The stack state at the time of syscall is defined by struct pt_regs in

asm-i386/ptrace.h. There are 3 trap gates to syscalls. lcall7 and lcall27

handlers where the stack state has to be realigned,and the function

corresponding to the struct exec_domain registered is called. But ret. path is

the same as in int 0x80 which is the normal method of a syscall,and jump to

kernel mode. system_call is the entry point to system_calls defined entry.S.

This does a SAVE_ALL by saving all the registers in the stack (as defined by the

structure \"struct pt_regs. (starts from low to high.So it should be ok.)\". After

storing,it gets the number of the system_call from %eax. Note: (hacknayed note)

In normal syscall_handling, the registers used are \"eax,ebx,ecx,edx,esi,edi,and

ebp(for six arguments which is the max limit.)\". \"eax\" contains the number of

the system_call.The rest contain the arguments passed with a max limit of 6.

(check out /usr/src/linux/include/asm-i386/unistd.h for the numbers of sys_calls

supported.(currently 221 syscalls, and also check out the syscall macro

wrappers, which use inlined assembly. (checkout inlined assembly tutorials from

Gnu.as its quite necessary to hack kernel code.) Using the number of the

system_call,it indexes into a pointer to a function table

(sys_call_table->entry.S) to call the function. Note that all of the system

call functions use \"asmlinkage\" which is a gcc macro (defined in

/usr/src/linux/include/linux/linkage.h),which tells gcc,to look for the

arguments of the system call, in the stack and not in registers,where they were

passed originally.And for ptrace,the route is quite different in the sense,that

if the task is ptraced (PT_TRACESYS),it jumps to tracesys ,which calls

syscall_trace,before indexing into the sys_call_table for calling the

corresponding routine and falling back to tracesys_exit to return to

ret_from_sys_call. When the system_call handler returns,the return value is

moved back to the saved \"eax\",and the call then goes through ret_from_sys_call.