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 {...}

Answer 1

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 a begin_trans/commit_trans. We later moved the transaction start/end deeper into individual system calls, but forgot to fix syscall().

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.