0

The "os161" operating system contains the following code. Specifically, where the syscalls are defined:

...

#include <kern/syscall.h>
...

#define SYSCALL(sym, num) \
   .set noreorder       ; \
   .globl sym           ; \
   .type sym,@function      ; \
   .ent sym         ; \
sym:                ; \
   j __syscall                  ; \
   addiu v0, $0, SYS_##sym  ; \
   .end sym         ; \
   .set reorder

...

SYSCALL(fork, 0)
SYSCALL(vfork, 1)
SYSCALL(execv, 2)
SYSCALL(_exit, 3)
SYSCALL(waitpid, 4)
SYSCALL(getpid, 5)
...

At the bottom, each syscall gets a number. I can't seem to figure out what is the use of these numbers.

I'm not asking about the use of syscall numbers, I'm asking for the use of the argument num to the macro SYSCALL. I can't find where it's being used.

Even when the syscall number is moved to v0, the argument num is not used. Instead, it moves a constant defined in the file kern/syscall.h:

...

#define SYS_fork         0
#define SYS_vfork        1
#define SYS_execv        2
#define SYS__exit        3
#define SYS_waitpid      4
#define SYS_getpid       5
...

How can the argument num be useful somehow?

Martin Rosenau
  • 17,897
  • 3
  • 19
  • 38
StackExchange123
  • 1,871
  • 9
  • 24
  • 1
    Pasting long copyright statement does not make it easier to understand the question. Consider editing and leaving only the relevant parts! – dash-o Aug 02 '20 at 06:18
  • @dash-o Sure. Thanks. – StackExchange123 Aug 02 '20 at 06:19
  • 1
    As far as I understand it is not used at all. I suspect a remainder of a previous version where the `SYSCALL` macro was used to also define `SYS_sym`, instead of putting these definitions in `kern/syscall.h`. As it is now it still has at least one benefit: even if the `num` parameter is ignored by the macro, the code still shows the syscall number of each installed syscall. Anyway, did you try to remove it and run some tests? – Renaud Pacalet Aug 02 '20 at 06:33
  • @dash-o Not sure your recommendation about copyright statement is that wise. The copyright notice you wanted to be removed explicitly states that it should not be removed... – Renaud Pacalet Aug 02 '20 at 06:57

1 Answers1

1

It is used for other tools to ease the maintenance of the source code.
The following is a quote from Understanding System Calls

syscalls.S: This file is created from syscalls-mips.S at compile time and is the actual file assembled into the C library. The actual names of the system calls are placed in this file using a script called callno-parse.sh that reads them from the kernel's header files. This avoids having to make a second list of the system calls. In a real system, typically each system call stub is placed in its own source file, to allow selectively linking them in. OS/161 puts them all together to simplify the makefiles. Adding new entries to callno.h automatically causes new user-level system call procedures to be defined when you re-build the user-level code. Each "SYSCALL(name,num)" macro statement in this file is expanded by the C pre-processor into a declaration of the appropriate system call function.

kern/syscall.h most likely is produce by one of those tools.

Pablo Yaggi
  • 1,061
  • 5
  • 14