CS137 Homework 1: Hello, World!

Overview

The purpose of this assignment is to get you familiar with FUSE. You will be writing a very simple pseudo-filesystem that duplicates and slightly extends the "Hello, world" example on the FUSE Web site. The extension is that the single file in your filesystem will not be read-only; instead, you will be able to write a short replacement message to your "hello" file.

You may write in any language that is supported on Wilkes, but as mentioned in class, I strongly recommend C or C++.

There are two ways to approach this assignment. The first is the lazy way: start with the hello.c example and make the quite minimal modifications needed to turn it into the required program. This is the foolish way to attack the problem.

The slightly more effortful, and much wiser, approach is to start with the more complex fusexmp.c and use hello.c as a guide, implementing stubs for all the functions that aren't needed in your simple program. In the process, you will familiarize yourself with much more of Fuse, learn how to return errors, and develop a framework that will be useful when you do Homework 2.

The Assignment

Your assignment is to develop a filesystem with the following characteristics:

  1. There is a single file, with a name of your choice. (I'll use "goodgeoff" as an example.)
  2. ls and ls -l work on the root directory, and return plausible values for ".", "..", and "goodgeoff". The length for the latter should be correct, even after it has been modified.
  3. The access() system call works and says that "goodgeoff" can be both read and written.
  4. When read, "goodgeoff" (or whatever your file is called) initially contains a short string of your choosing (e.g, "Good Geoff!"). For cosmetic reasons, it should be terminated by a newline, but should not include a trailing null byte. If a write has been done, "goodgeoff" should contain the data written (see below).
  5. When written, "goodgeoff" should accept a number of bytes up to the length of the original string. (This length restriction is just to make your life easier; you are welcome to get fancier.) A write longer than the original length can be rejected with an appropriate error code, can be silently accepted up to the original length, or can extend the string. (Note that implementing write correctly requires that you also implement truncate.)
  6. Other operations are up to you. If you take the non-lazy approach, anything unimplemented should return an error code; I recommend ENOSYS. (The complete list of error codes can be found in /usr/include/asm-generic/errno*.h; I recommend sticking with the ones below about 50.)

Practical Details

You can do your development on any machine you choose that supports FUSE; however, your final code will be tested on Wilkes and must run there. Mac users can try macfuse; Linux users should be able to find FUSE as part of their distribution.

A Note on Compiling

Compiling a FUSE program requires a slightly complicated command:

/usr/bin/gcc -g `pkg-config fuse --cflags --libs` my_hello.c -o my_hello
A better approach, of course, is to use make. This truly minimal Makefile will let you type "make foo" for any foo.c. You are encouraged to use it and extend it to be more sensible. NOTE: On Wilkes, be sure to use "/usr/bin/gcc" rather than just "gcc". Wilkes is specially configured so that plain gcc produces 32-bit code, but for this assignment you need 64-bit code.

Writing the Code

Writing a Fuse client is complex enough to be worth a separate Web page with reference materials.

Running & Testing

The class FUSE documentation page contains instructions on how to run and debug FUSE programs in general. For this assignment, be sure to test not only that you can read your file, but that you can write to it (I suggest a command such as "echo wowee > testdir/hello") and that you get back precisely what you wrote.

Submission

Submit your code (it should be a single file) with cs137submit. If you implement any additional features, describe them prominently in comments at the top of the file.


© 2014, Geoff Kuenning

This page is maintained by Geoff Kuenning.