Advice:

• Get started right away. You have only one week to do it.

• If you encounter problems, ask the instructors, either in the lab after class, by e-mail, or by telephone.

• In debugging, you can save time by splitting up the load/unload scripts, so that they don't create and destroy the /dev/scull* device nodes every time. If the device major number does not change, you can create them once and just keep reusing them until you need to change the device major number.

  If you make this change, your testing cycle will be as follows:

  1. make nodes for devices in /dev directory
     use a script; make sure you get it right!
  2. compile module
  3. insert module
  4. exercise module
  5. remove module
  6. if necessary, edit module source code and go back to step 2
  7. delete nodes in /dev
     use a script; beware of deleting other nodes!

• For testing, you can start using scripts and shell commands, like cat, dd, but this is limited in the scope of what can be tested. For thorough testing, you will need to write some programs in C, using the system API. For a starting point, see sculltest.c.

• You will need to perform the following steps.

  1. Get, compile, and test the basic scull module.
  2. Make a copy of pipe.c under a different name, "lifo.c", and revise at least all exported names to make them different from those in pipe.c
  3. Add your new file to the object files in the Makefile.
  4. Add any necessary support for your new device subtype to lifo.h and main.c.
  5. Revise the data structure to implement a stack rather than a pipe.
  6. Revise the read and write routines to implement the stack semantics (including reversal of character ordering on reads).
  7. Create your own ioctl routine, with just the one command supported.
  8. Modify scull_load and scull_unload to create the appropriate device node(s) for your new device(s), or use these as templates to write your own lifo_load and lifo_unload scripts, that only create the node(s) needed for your LIFO.
  9. Compile and test your framework/prototype, using appropriate test programs/scripts that you have written.
  10. Save your tests, for the demonstration.
      You will also want to modify the Makefile to add targets for all of your tests.

  You probably want to do the above incrementally, maybe starting with just a duplicate of the pipe code (no changes) that will compile and which you can test. Then change the code to implement the stack read and write, maybe without character string order reversal, and test. Then add the order reversal, and retest. Then add the new ioctl function, and retest. That way, if you don't get it all done you will have something to turn in.

• Let me know if you run into any problems. I will do what I can to help, and if it is a problem whose solution may be of interest to other students I will send an e-mail about it to the entire class.

References:

• the textbook
• the example source files that came with the text

Delivery Method:

1. Turn in the following, as hard copy, in class on the due date:

   • Copies of the files that you modified, with the parts you modified pointed out in some clear way (e.g. marked colored highlighter).
   • Copies of test scripts and/or programs you used.

2. Also e-mail me the electronic copies of the above. For simplicity, I would prefer that everyone send me a uuencoded gzipped tarfile. If your code is in directory prog2, you can do this on a Linux machine that supports mail (e.g., quake) as follows:

   tar cvpf - prog2 | gzip -c | uuencode prog2.tgz | mail -s "prog2" baker@cs.fsu.edu

   This uses tar to create an archive, which it pipes for compression to gzip, which pipes the compressed file to uuencode for conversion to ASCII characters, which pipes it to mail.

   The code above worked fine on websrv, and I expect it should work equally well on quake but if you are mailing from a Solaris machine (Are they finally all phased out of this deparment?) you will either need to leave out the -S "prog2" argument to mail, or use mailx instead. You may also need another argument for uuencode.

   The electronic copy can be later than the hard copy. I would prefer work from the hard copy and the demo for evaluation purposes. (I mainly want the electronic copy for archival purposes, including accreditation. The outside reviewers always ask for copies of student work in each course.)

3. Sign up of a time slot to demonstrate your code to the instructor.

Assessment:

If you do everything that is required and explain it adequately at the demonstration you will receive a perfect score. Deductions will be made for skipped steps, steps done incorrectly, or inability to explain. Pay attention to the quality of the tests that you prepare for the demonstration.

During the demonstration, I will be looking to verify that you can demonstrate tests for all the required functionality. I will be looking for answers to the following questions:

• Can you compile and load the kernel module?
• Can you explain your code, and answer questions about both what you did and why you did it that way?
• Do you have the test scripts or programs (better) ready to go?
• Have you tested that the read behavior satisfies item (6) above? That is:
  • Does it behave as a FIFO behavior the character level? For example, if you write "abcde" and "fgh" but then read back 5 characters, do you get "hgfed" back? (not "fghab")
  • When a read asks for more characters back than are in the FIFO, does it return all those that are left?
  • When a read encounters no data in the buffer, does it block if-and-only if the file was not opened with the O_NONBLOCK option?
• Have you tested that the write call loops and blocks until the entire string has been written, as specified above? That is:
  • When a write tries to write more characters into the FIFO than it can hold, does it block if-and-only if the file was not opened with the O_NONBLOCK option?
  • Reading from the LIFO consumes the data.
  • When it blocks, and then a subsequent read creates more space, does it unblock?
• Have you tested the IOCTL operation for emptying the FIFO?
• Have you tested that the LIFO works correctly when shared between processes? In particular:
  • Have you tested the FIFO when opened by more than one process at a time?
  • Does the LIFO function work with a concurrent reader and writer?
  • Does it work correctly with multiple readers? multiple writers?
  • If one process puts data into the FIFO, and then closes it, is the data still there when another process reads it?
  • Have you maintained the correct use of semaphores to protect critical sections? Does the protection cover all operations that access the device data? (reads? writes? IOCTLs?)
• Have you preserved the old types of devices when you added your new device, withough breaking any of them or introducing possibilities for unchecked incorrect usage?
• Do the operations on your new device have any useless code, perhaps left over from cutting and pasting? An extra pointer for the bottom of the stack? Code to wrap around the end of the buffer? IOCTLs that don't make any sense for a LIFO?
• Have you checked the validity of all calls on your device? In particular, do you check for validity of IOCTL calls? (You cannot just modify the existing scull_ioctl(). You need to override it with a function specific to LIFOs.)
• Have you used RCS or CVS?
• Do you have any special creative features, that you invented, not required by the assignment?