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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
|
.TH SYS-INTRO 2
.SH NAME
Sys: intro \- introduction to the
.B Sys
module
.SH SYNOPSIS
.EX
include "sys.m";
sys := load Sys Sys->PATH;
.EE
.SH DESCRIPTION
Inferno system calls are provided by the built-in module declared by
.BR sys.m .
It contains the fundamental system data structures and interfaces.
There are currently 42 calls, providing: file access; basic I/O;
name space manipulation; formatted output
for Limbo; and basic character and string manipulation.
.SS "File Name Space"
Files are collected into a hierarchical organization called a
.I file
.I tree
starting in a
.I directory
called the
.IR root.
.IR Filenames ,
also called
.IR paths ,
consist of a number of
.BR / -separated
.I "path elements
with the slashes corresponding to directories.
A path element must contain only printable
characters (those outside ASCII and Latin-1 control space).
A path element cannot contain a slash.
The path element
.B \&..
refers to the parent directory of the directory containing that element.
.PP
When a process presents a file name to Inferno,
it is
.I evaluated
by the following algorithm.
.TP
1.
Start with a directory that depends on the first character of the path:
.B /
means the root of the main hierarchy,
.B #
means the separate root of a kernel device's file tree
(see Section 3),
and anything else means the process's current working directory.
.TP
2.
For each path element, look up the element
in the directory, advance to that directory,
do a possible translation (see below).
.TP
3.
Repeat.
The last step may yield a directory or regular file.
.PP
The collection of files reachable from the root is called the
.I "name space
of a process.
.PP
A program can use
.B bind
or
.B mount
(see
.IR sys-bind (2))
to say that whenever a specified file is reached during an evaluation,
that evaluation continues instead from a second specified file.
Also, these same calls create
\f2union directories\fP,
which are concatenations of ordinary directories
that are searched sequentially until the desired element is found.
Using
.B bind
and
.B mount
to do name space adjustment affects only
the current name space group (see below, and
.IR sys-pctl (2)).
Certain conventions about the layout of the name space should be preserved;
see
.IR namespace (4).
.PP
The operating system kernel records the file name used to access each open file or directory.
If the file is opened by a local name (one that does not begin
.B /
or
.BR # ),
the system makes the stored name absolute by prefixing
the string associated with the current directory.
Similar lexical adjustments are made for path names containing
.B .
(dot) or
.B ..
(dot-dot).
By this process, the system maintains a record of the route by which each file was accessed.
Although there is a possibility for error\(emthe name is not maintained after the file is opened,
so removals and renamings can confound it\(emthis simple method usually
permits the system to return, via
.IR sys-fd2path (2)
and related calls such as those of
.IR workdir (2),
a valid name that may be used to find a file again.
This is also the source of the names reported in the name space listing of
.IR ns (1)
or the
.B ns
file of
.IR prog (3).
.SS "File I/O"
Files are opened for input or output
by
.B open
or
.B create
(see
.IR sys-open (2)).
These calls return a reference to an object of type
.B FD
(file descriptor)
that identifies the file to subsequent I/O calls,
notably
.B read
and
.B write
(see
.IR sys-read (2)).
When the last reference to an
.B FD
disappears, the file descriptor is released\(emclosed, in Unix parlance.
The
.B FD
contains an integer file descriptor, similar to those in Unix, but the
.B FD
type is the one passed to Limbo I/O routines.
.PP
Integer file descriptor values range from 0 to
.I n
in the current system, where the upper bound
depends on the underlying operating system.
The system allocates the numbers by selecting the lowest unused descriptor.
They may be reassigned using
.B dup
(see
.IR sys-dup (2)).
Integer file descriptor values are indices into a
kernel-resident
.IR "file descriptor table" ,
which is inherited from the parent when a process is created by a Limbo
.B spawn
operation.
A set of processes, called a
.IR "file descriptor group" ,
shares that table, so files opened by one process may be
read and written by other processes in the group. See
.IR sys-pctl (2)
for more information.
.PP
By convention,
file descriptor 0 is the standard input,
1 is the standard output,
and 2 is the standard error output.
The operating system is unaware of these conventions;
it is permissible to close file 0,
or even to replace it by a file open only for writing,
but many programs will be confused by such chicanery.
.PP
Files are normally read or written in sequential order.
The I/O position in the file is called the
.IR "file offset"
and may be set arbitrarily using the
.B seek
system call
.RI ( sys-seek (2)).
An offset can also be passed as a parameter to
.B pread
and
.B pwrite
(see
.I sys-read (2)).
.PP
Inferno provides no guarantee of consistency should
several processes access a file concurrently.
Guaranteed synchronous writes are not available.
Whether the exclusive-use attributes described in
.IR sys-open (2)
and
.IR sys-stat (2)
will be honoured for a file depends entirely on the underlying file server
(eg,
.IR fs (3)).
Record locking in the underlying file system is not supported by Inferno.
Processes can coordinate their file operations by other mechanisms.
.PP
Atomicity is guaranteed for byte counts smaller than the
.I Styx
message size;
see
.IR read (5).
.PP
Directories may be opened and read
much like regular files (see
.IR sys-dirread (2)).
They contain an integral number of records,
called
.IR "directory entries" .
Each entry is a machine-independent representation of
the information about an existing file in the directory,
including the
name,
ownership,
permission,
access dates,
and so on.
.PP
The entry
corresponding to an arbitrary file can be retrieved by
.B stat
or
.B fstat
(see
.IR sys-stat (2));
.B wstat
and
.B fwstat
write back entries, thus changing the properties of a file.
.PP
New files are made with
.B create
and deleted with
.B remove
(see
.IR sys-open (2)
and
.IR sys-remove (2)).
Directories may not directly be written;
.BR create ,
.BR remove ,
.BR wstat ,
and
.B fwstat
change them.
.SS "Process execution and control"
A Limbo
.IR process ,
also called a
.IR thread ,
is the basic unit of computation for Limbo application programming
in the Inferno operating system.
.PP
A newly spawned thread shares the same
.I "address space
as that of its creator thread.
That is, the set of global variables that is in scope to
one is in scope to the other.
A change made by one can be detected by the other.
Since they are scheduled independently,
they should synchronize their
actions to share this data coherently.
.PP
The newly created thread also shares the same set of open file descriptors
and the current working directory.
.PP
Processes are also organized into
.I "process groups
.RB ( pgrps )
that represent the set of threads of a single
application and can be terminated by a single kill request; see
.IR prog (3).
.PP
A newly-spawned thread automatically inherits the following attributes:
file name space (including shared
current directory); file descriptor group; and process group.
A thread can subsequently
acquire a new, independent name space, new or modified file descriptor group,
or new process group.
See
.IR sys-pctl (2).
.SS "User/Group Identity"
The Inferno operating system maintains user identifier
.RB ( uid )
and group identifier
.RB ( gid )
strings
for each process.
These values are also attributes of files and directories.
See
.IR sys-stat (2)
and
.IR stat (5).
A comparison of process and file identities take place when a process
attempts to open or create a file.
.PP
When a pathname crosses from one server to another the process identities are
mapped by each server receiving a file request.
.PP
The
.B uid
and
.B gid
strings are assigned to the thread created
when a user logs into Inferno and cannot be changed.
.SH SOURCE
.B /emu/port/inferno.c
.br
.B /os/port/inferno.c
.SH DIAGNOSTICS
System calls often return an integer status, or tuples containing results and
an integer status,
and follow the convention that a status of -1 is returned when an error occurred;
a non-negative value (usually 0) is returned on success.
If an error occurred, a detailed error message can be obtained for the
most recent error, using the
.RB ` %r '
format of
.IR sys-print (2).
Exceptions to this general rule are noted in the
`DIAGNOSTICS' sections.
.PP
From Limbo, system calls that return values on the heap, for instance strings in
.B Dir
structures returned by
.IR sys-stat (2),
and arrays of directory entries returned by
.IR sys-readdir (2),
can also raise ``out of memory: heap'' exceptions when attempting
to create the return value.
|