summaryrefslogtreecommitdiff
path: root/system_call.mdwn
blob: d8a465b454f9b1add964d08c782ab8503d66b494 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
[[!meta copyright="Copyright © 2010, 2013, 2014 Free Software Foundation,
Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

In an [[UNIX]]-like system, a *system call* (*syscall*) is used to request all
kinds of functionality from the operating system kernel.  On GNU/Linux, glibc
translates function calls to system calls by packing arguments appropriately
and using that trap or syscall instruction.

A [[microkernel]]-based system typically won't offer a lot of system calls --
apart from one central one, and that is *send message* (mach_msg) -- but
instead [[RPC]]s will be used instead.
See [[GNU Mach's system calls|microkernel/mach/gnumach/interface/syscall]].

In the [[GNU Hurd|hurd]], a lot of what is traditionlly considered to be a UNIX
system call is implemented (primarily by means of [[RPC]]) inside [[glibc]].


# IRC, freenode, #hurd, 2013-06-15

    <braunr> true system calls are always implemented the same way, by the
      kernel, using traps or specialized instructions that enable crossing from
      user to kernel space
    <braunr> glibc simply translates function calls to system calls by packing
      arguments appropriately and using that trap or syscall instruction
    <braunr> on microkernel based systems however, true system calls are
      normally used only for IPC
    <braunr> so we also use the term syscall to refer to those RPCs that
      provide system services
    <braunr> e.G. open() is a call to a file system server (and maybe several
      actually)


# IRC, freenode, #hurd, 2013-11-02

    <Hiryu> how do system calls work in the hurd?
    <Hiryu> is it like in linux
    <braunr> yes and no
    <Hiryu> you set the number in %eax and then in0x80?
    <Hiryu> int, even
    <braunr> no
    <braunr> but that's really a detail
    <Hiryu> I'm just curious how the flow goes
    <braunr> gnumach uses call gates, not interrupt gates
    <braunr> but that's just another way to enter the kernel
    <braunr> the mechanism itself is almost irrelevant, it matters only for
      performances
    <Hiryu> ah
    <braunr> what's truely interesting is that there are very few system calls
    <Hiryu> so it goes straight to gnumach, which then figures out where to
      relay the call to?
    <braunr> the main one being mach_msg
    <braunr> yes
    <braunr> one of the arguments to mach_msg is the name of a right
    <braunr> (as file descriptors are names for open files)
    <Hiryu> hmm okay, so we get to the kernel, go to a kernel server (one
      context switch), then get back to the calling process, and that's 2
      context switches per system call?
    <braunr> a receive right or send right
    <braunr> no
    <braunr> if you send-recv, it's only one
    <braunr> but i'm not sure we do that on the hurd
    <braunr> again, that's a detail
    <Hiryu> what is send-recv?
    <braunr> send and receive in the same system call
    <Hiryu> hmm
    <braunr> then, we also use system calls to denote the unix-like RPCs of the
      hurd
    <braunr> i mean
    <braunr> i also call them system calls
    <braunr> for example, read, write, stat, etc..
    <Hiryu> I see
    <Hiryu> braunr: thanks