[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haiku-development
Subject:    [haiku-development] Re: g++ command line
From:       Ingo Weinhold <ingo_weinhold () gmx ! de>
Date:       2014-02-23 12:44:19
Message-ID: 5309ED23.10206 () gmx ! de
[Download RAW message or body]

On 02/22/2014 10:29 PM, Denis Papin wrote:
> > Because programs are linked to libroot by default, which contains the
> > libc and the syscall entry points.
> 
> I can then track it down to the src/system/libroot/os/team.c  that defines the \
> _get_next_team_info as a call to _kern_get_next_team_info  which is defined as a \
> system call in syscalls.h I guess the "pragma syscalls begin" is where the secret \
> lies. 
> But I am bumping into another mystery. Where is the _kern_get_next_team_info \
> actually coded.

A file syscalls.S.inc (placed in 
objects/haiku/<arch>/common/system/libroot/os) is auto-generated by 
src/tools/gensyscalls/Jamfile from the syscalls header file 
headers/private/system/syscalls.h. It defines the libroot syscall 
functions by use of macros which expand to the architecture specific 
syscall invocation code.

The control flow then enters the architecture specific syscall entry 
point in the kernel (e.g. x86_sysenter() in 
src/system/kernel/arch/x86/32/interrupts.S), which in turn dispatches 
the syscall to the corresponding _user_*() function in the kernel. In 
your case that would be _user_get_next_team_info() in 
src/system/kernel/team.cpp.

So, leaving all the magic out, the short story is that calling a 
_kern_foo() syscall in libroot ends up calling a _user_foo() in the 
kernel. If you want to add a new syscall, just add the _kern_*() 
prototype to headers/private/system/syscalls.h and the implementation of 
a corresponding _user_*() function somewhere in the kernel.

CU, Ingo


[prev in list] [next in list] [prev in thread] [next in thread]