Submit: Turn in your
entire xinu-hw10 directory source files
using the turnin command
on morbius.mscsnet.mu.edu or one of the other
Systems Lab machines. Please run "make clean" in
the
compile/ subdirectory just before submission to reduce
unnecessary space consumption.
Work should be completed in pairs. Be certain to include both names in the comment block at the top of all key source code files, with a TA-BOT:MAILTO comment line including any addresses that should automatically receive results. It would be courteous to confirm with your partner when submitting the assignment.
Start with a fresh Xinu Homework 10 tarball for this assignment. The new tarball includes working versions of all of the previous assignments, and several new subsystems we have not had time to build in class.
Untar the new project files:
tar xvzf ~brylow/os/Projects/xinu-hw10.tgz
The project tarball includes an implementation for a device driver layer, providing functions for: open, close, read, write, getc, putc, and control. The device layer allows user programs (such as the processes in main.c) to work with device-specific functions using standard names such as open() and read(), rather than have to explicitly name the underlying device driver.
You do NOT need to make any changes to the device interface layer files.
With the addition of a full-featured TTY driver, we can now add the command-line Xinu user interface, the Xinu Shell to the system. The new tarball includes a new subdirectory shell/ that provides the I/O processing necessary to parse user input and launch a small set of commands. Several useful commands are provided as examples. This assignment will be concerned primarily with the pre-implemented file system commands diskstat, cat and delete.
The project tarball equips Xinu with a block I/O device driver (running over the second serial port) that speaks to a xinu-disk program running on your computer. The xinu-disk process maps reading and writing requests from the backend to a locally-stored disk file. In this way, your O/S can behave as though it has a small (64K) disk attached, and the storage is really a file in your home directory.
See below for additional details on the xinu-disk command.
The project tarball includes a partial implementation of a small file system. The first block of the "disk" is expected to contain a superblock which contains vital bookkeeping information about the file system, such as:
The new header files disk.h and file.h contain the necessary constants and structures to build the file system. Take a look at file/file*.c (file source code,) and file/sb*.c (superblock source code.)
Our disk has 256 blocks of 256 bytes each. The free disk block list is dynamic, but our directory index is limited to a fixed number of files, with fixed length names, and fixed maximum sizes. (The problems and solutions associated with these limitations would each make excellent final exam questions, by the way.)
You have two subtasks. The first is to add file deletion (fileDelete()) and free block removal (sbFreeBlock()) into the system. The second is to extend the directory index system to allow a linked list of directory index nodes as the number of files increases.
The project tarball includes shell commands for listing the status of the file system data structures, diskstat, that you may find useful in quashing bugs in your assignment. Diskstat prints a summary of the files currently on the system, as well as an overview of the current list of free disk blocks.
The cat command in the shell serves two functions:
The delete command allows you to conveniently delete files in the current disk image, once you have implemented the underlying file system commands.
Provide a test command (see shell/xsh_test.c) that demonstrates that your fileDelete() and sbFreeBlock() calls are working properly.
The command "xinu-disk" starts up a disk daemon on the local server that can provide disk access to the selected backend machine via its second serial port. Build the disk daemon by running "make xinu-disk" in your compile/ directory. For example, to test my file system on backend "Voc" using a local disk image called "foo.dat", I would run the command "mips-console voc" in one terminal, and then execute "./xinu-disk foo.dat voc2" in a second terminal within the first ten seconds of my kernel booting.
Xinu-disk's ability to synchronize with a "moving-target" backend is somewhat rudimentary -- you may occasionally see the handshake fail upon startup. Just close out the mips-console session normally, close the xinu-disk process with a "Control-C", and try again.
The command "xinu-status" will list the users on each backend, and "xinu-status -c uart" will list the users on each backend's second serial port. Also recall that a user can bump another user off of a specific backend after 10 minutes of activity.
[Revised 2020 Apr 22 14:11 DWB]