xv6 rev6 strange code in syscall()
Question
Any one can see why the following ifs, lines 3279-3285 in xv6-rev6 code, are used:
int num;
num = proc−>tf−>eax;
if (num >= 0 && num < SYS_open && syscalls[num]) {
proc−>tf−>eax = syscalls[num]();
} else if (num >= SYS_open && num < NELEM(syscalls) && syscalls[num]) {
proc−>tf−>eax = syscalls[num]();
} else {...}
and not just:
int num;
num = proc−>tf−>eax;
if (num >= 0 && num < NELEM(syscalls) && syscalls[num]) {
proc−>tf−>eax = syscalls[num]();
} else {...}
Solution
My original answer is below, which is partially right.
I took the liberty of contacting the authors at MIT and received the following response:
The code in the second half of the
if
wrapped the system call in abegin_trans/commit_trans
. We later moved the transaction start/end deeper into individual system calls, but forgot to fixsyscall()
.
So the two parts were different and, when they were changed to be the same, the modification simply didn't merge the two bits back together.
No, those two bits of code are equivalent.
It may be that at some point the calls to syscalls[?]()
was different somehow, either with parameters or return locations but that's not the case now.
There may also have been a gap of some sort in there, something which may be supported by the fact there's a blank line at line 3115:
// System call numbers
#define SYS_fork 1
#define SYS_exit 2
#define SYS_wait 3
#define SYS_pipe 4
#define SYS_read 5
#define SYS_kill 6
#define SYS_exec 7
#define SYS_fstat 8
#define SYS_chdir 9
#define SYS_dup 10
#define SYS_getpid 11
#define SYS_sbrk 12
#define SYS_sleep 13
#define SYS_uptime 14
#define SYS_open 15
#define SYS_write 16
#define SYS_mknod 17
#define SYS_unlink 18
#define SYS_link 19
#define SYS_mkdir 20
#define SYS_close 21
This is the entire contents of syscalls.h
and the blank line is somewhat suspicious.
There's no obvious functional grouping - though all the ones 15 and above seem to be related to file system manipulation, SYS_read
and SYS_fstat
are in the first group.
Maybe you should contact the authors to ask them (6.828-staff at pdos.csail.mit.edu
).
I know (since I have the book) that it's not carried over from the Lions-era code since that has no such gaps in the list - they're also in a different order as well, with read and write next to each other for example.