Today's plan

Minix Opening and Closing

common_open (p. 835)
may create a new file, by calling new_node (p. 838), which allocats an inode then adds the name and the inode to the directory entry
allocates an in-memory inode and filp and initializes them
checks protections
does type-specific operations for regular files, directories, block- and character-special files, and pipes
e.g. for regular files, truncates them (by returning all the blocks and clearing the inode) if the open requested truncation
mknod and mkdir do what is needed, e.g. mkdir creates the "." and ".." links
search_dir (p. 865) edits or serches the directory
last_dir (p. 862) returns the inode of the last directory in the path

reading and writing are the almost the same (read_write, p. 843):
- 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. 846) does the actual (partial) block transfer, using read_map (p. 847) to obtain the address of an existing block
rw_chunk may have to call new_block (p. 854) if writing to an as-yet-unwritten part of the file
new_block uses write_map (p. 852) 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, 7KB)
when the file has been read completely, the write position is reset to the beginning (line 23570, p. 845)
on a read, wake up any sleeping writers (check_pipe, p. 858, line 24413)
on a write, wake up any sleeping readers
the "file" has an inode and a filp, but no directory entries (usually -- a "named pipe" might have 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 updated 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, e.g. line 25598 on p. 874

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. 858) copies the system call number and parameters to the process table, and avoids replying to the caller
release (p. 858) calls revive for any process waiting on a given system call (e.g. writing) on a given pipe
revive (p. 858) either sets a flag (line 24542), or directly replies to the suspended process (lines 24547 and 24551)
the main loop of the file system process calls get_work (p. 829), which checks to see if any processes are being revived, 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

call_task (p 898) tries to send a message to a task, and is prepared to receive a completely unrelated response
fetch_name (p 900) 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 (p. 902) 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

Do we really care where our computer lives?
- no -- as long as we can access all our files and run all our programs
- yes -- for security
benefits of distributed computing: the right number of computers at the right time
challenges of distributed computing:
- providing fast access to computing power
- providing fast access to data (files)
- providing secure access and computing
the computing environment may be as important as the computing itself -- fortunately, Unix-like systems have supported distributed environments well, e.g. remote window clients via X windows (1980s), secure logins such as SSH (late 1990s)
Windows environments have supported a different subset of distributed access, mostly access to data