Outline

Minix Reading and Writing

reading and writing are the almost the same (read_write, p. 973):
- check protections, sizes
- find the correct block to read or write (perhaps allocating a new block)
- copy the data to or from the block
both reading and writing only access up to the next block boundary in a single iteration of the main loop
rw_chunk (p. 977) does the actual (partial) block transfer, using read_map (p. 978) to obtain the address of an existing block
rw_chunk may have to call new_block (p. 985) if writing to an as-yet-unwritten part of the file
new_block uses write_map (p. 983) to do the hard work of allocating new zones in an inode, including the indirect and double-indirect blocks

pipes are treated almost like files, except:
the maximum size is limited to PIPE_SIZE (7 blocks, 28KB) -- all directly accessible from the inode
when the file has been read completely, the write position is reset to the beginning (line 25202, p. 976)
on a read, wake up any sleeping writers (pipe_check, p. 988)
on a write, wake up any sleeping readers
the "file" has an inode and a filp, but no directory entries (unless it is a "named pipe", which has a directory entry)

linking adds a new link to an existing file
unlinking removes an existing link to a file or directory
rmdir is a slightly safer (more error checking) version of unlink
when unliking a directory, must remove the "." and ".." entries and update the parent's link count
renaming is almost like link followed by unlink, but slightly optimized to still work even when the disk is full
renaming also allows renaming directories, whereas linking directories is only allowed to the superuser
linking directories is dangerous because it introduces the risk of having loops in the file system hierarchy -- this could lead to infinite loops in the file system, which might be bad, e.g. line 27197 on p. 1007

any process making a "slow" system call (read or write on a pipe, read on a terminal) may be suspended, in which case the system call must be retried later
suspend (p. 989) copies the system call number and parameters to the process table, and avoids replying to the caller
release (p. 990) calls revive for any process waiting on a given system call (e.g. writing) on a given pipe
revive (p. 991) either sets a flag (line 26170), or directly replies to the suspended process (lines 26175, 26177, and 26181)
the main loop of the file system process calls get_work (p. 959), which checks to see if any processes are being revived (line 24109), and only if none are being revived, then calls receive
if processes are being revived, the system call number and arguments are taken from the process table rather than from the message received

gen_io (p 1027) tries to send a message to a task, and is prepared to receive a completely unrelated response
fetch_name ( utility.c, not in book) takes an argument name either from the message (if it is short), or by copying bytes from user space (for a long argument) -- the library must of course set up the message accordingly
conv2 and conv4 (utility.c) do byte-swapping if the byte ordering on the disk is not the same as the byte ordering of the machine -- this may also be needed for networking