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
Minix Reading and Writing
- 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
Minix Pipes
- 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)
Minix Linking and Unliking
- 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
Minix FS system call retry
- 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
Minix FS miscellaneous calls
- 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
Distributed Computing: Concepts
- 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