|
The code below illustrate a good example of WHAT IS ESSENTIAL during a
system call in the legacy era. http://lkml.org/lkml/1996/11/5/38 Hello hackers, I was reading the system call entry code in arch/i386/kernel/entry.S. This is from 2.1.7:
ENTRY(system_call)
pushl %eax # save orig_eax
SAVE_ALL
GET_CURRENT
#ifdef __SMP__
ENTER_KERNEL
#endif
movl $-ENOSYS,EAX(%esp)
cmpl $(NR_syscalls),%eax
jae ret_from_sys_call
movl SYMBOL_NAME(sys_call_table)(,%eax,4),%eax
testl %eax,%eax
je ret_from_sys_call
testb $0x20,flags(%ebx) # PF_TRACESYS
jne tracesys
call *%eax
movl %eax,EAX(%esp) # save the return value
ALIGN
.globl ret_from_sys_call
ret_from_sys_call:
First, I have a question about the ALIGN that appears right before
ret_from_sys_call.
In the fast path through the code, %eax is going to have a valid system
call number in it, and the PF_TRACESYS flag is not going to be set. In
this case, aligning ret_from_sys_call will not have any advantage on any
processor ever. It will just insert a few more NOP instructions into
the execution path.
Second, I think these two instructions can be bummed:
testl %eax,%eax
je ret_from_sys_call
Instead of filling up sys_call_table with zeros, how about filling it up
with the address of sys_ni_syscall? That would not take any more memory
(the table would have the same defined length).
There would be a side effect on strace because it would now see all 256
system call numbers and it would have to expand one of *its* tables.
But hey, I think it's worthwhile in order to shrink the system call
overhead a little bit more.
What do you think?
Michael Chastain
[email protected]
|
