COP 4600 - Operating Systems (Fall 2012)

Instructor: R. Newman
Email:       nemo@cise.ufl.edu

Notices

• 11/25: TA evaluations are at: https://evaluations.ufl.edu. Please complete evaluations by Friday, December 7th.
• 11/16: Updated to indicate the modifications to LS are extra credit worth 10 pts (out of 100).
• 11/8: Ryan will be holding special office hours in the dungeon (CISE lab), Sunday(11/11) 4pm-7pm. Please have at least completed chacl.
• 11/7: Added Project 3, section created to provide clarifications (check frequently).
• 10/16: Clarified the need for documentation (same as project1) for Project2.
• 10/13: Made some small changes to the Project 2 notes based on emails I've received. All changes are highlighted in red.
• 10/11: Added Project 2 tips
• 9/21: Ryan's 1-2PM office hours are cancelled today. The 4-5 office hours will instead be from 4-6PM today. Thank you.
• 8/29: Discussion Slides #1

Project Assignments

1. Project 1
2. Project 2
3. Project 3 (Located on Sakai)

FAQ

• Project 3 Clarifications:
  • Hint: Supporting ACLs within Minix should only require modifying code within VFS, try to limit your search scope to source code within VFS. *NEW* A small portion of code is necessary in MFS as well to support a boundary condition, this can be addressed after writing all code in VFS.
  • Chacl: The chacl command line program is capable of setting ACL user/group permissions for any given file, directory, symlink, etc.
    • Usage: chacl -[ug] name [+-][RWX] filename(s)
    • Example: chacl -u nemo +rw testFile.txt /usr /home/testFile2.txt
    • Example: chacl -g testGroup -r test.txt
    • Assume arguments are ordered as specified above to simplify argument parsing.
    • -[ug] : Specifies whether the following string should be interpreted as a username or a groupname. E.g, -u nemo Specifies the user nemo, -g testGroup specifies the group testGroup.
    • [+-][RWX] : Specifies whether to add(+) or remove(-) the trailing permissions. R = Read, W = Write, X = Execute. E.g, +rw grants read/write permission. -r Removes read permission (if they had permissions previously).
    • filename(s) : After the username/groupname and permissions are specified, an arbitrary number of filenames/pathnames may be specified. For each of these files the permission must be added/removed to the specified user/group. These filenames can be specified in either absolute or relative paths.
    • Note1: Chacl will ultimately need to pass(IPC) the above information to VFS (Virtual File System) to set the ACL. This will be done through a new system call (Refer to Project #1).
    • Note2: Passing the filename is tricky given the IPC message structure (/usr/src/include/minix/ipc.h). Refer to the chmod system call and how VFS retrieves a filename from it. Chmod is a good source of information for how Chacl should work. Refer to /usr/src/commands/chmod.
    • Note3: Usernames and Groupnames must be converted into UIDs and GIDs. There is built in functionality for this already within Minix so search for these methods to assist you.
    • Hints: You can create new users or groups by using the useradd or groupadd respectively. For more information on these commands refer to their manpages. It is recommended that you assign specific UIDs and GIDs to your created users/groups so you can easily determine if chacl is referencing the correct users/groups.
  • VFS modifications:
    • Currently ACLs do not exist within VFS at all. This functionality must be implemented from scratch, but there are lots of functions and code that can be reused from VFS to accomplish this goal.
    • The majority of the work will be within VFS and will require a nontrivial amount of code to be written to support ACLs.
    • Hints: These are some questions you should ask yourself when trying to add ACLs to VFS. All of the answers are within VFS if you look at and understand the code.
      1. Q: How do I retrieve information from the system call (i.e, UID/GID, filename, mode)?
      2. Q: How do I use the filename to find the file's vnode? Why do I need the file's vnode? How does do_chmod use the filename?
      3. Q: Assuming I can find the file's vnode, how do I check if the user is allowed to set an ACL for a file? (Only file owners or superusers can set it) How does do_chmod check this condition?
      4. Q: How do I save a new access control to the ACL file? What should I store in the ACL file so they can be retrieved and used later? How does VFS read/write to files so I can do something similar?
      5. Q: How do the new ACLs actually change the permissions for someone accessing a file? Where are the standard permissions being enforced? Can I extend that method to support checking ACLs as well?
    • Hint: How VFS handles chmod system calls is a good starting point for determining the types of changes you must make.
    • Hint: The above questions provide a path to piecewise solve the project. If you can solve one question it should lead you to the next until you have completed all of them.
    • Hint: When you borrow code from other functions, ensure that you understand what it is doing and what other parts of the code might be related to its operation. You can easily cause system panics if parts of the code are left out.
    • Hint: Read/Writing from/to files from VFS cannot simply use fopen/fread/fwrite/close. Those file functions use VFS to work, but VFS is already processing your do_chacl so calling one of those functions will simply cause VFS to deadlock. Find and use the raw readwrite command within VFS.
  • LS modifications: *NEW* This is extra credit worth 10 points.
    • LS must be modified to support viewing all ACLs set for a given file/directory.
    • LS will require a new system call to retrieve ACLs from VFS. Due to there being an arbitrary number of ACs for a given file, the system call to retrieve the ACL will need to account for this scenario.
    • The source code for LS exists within /usr/src/commands/ls.
• Project 2 Clarifications:
  
  • Project Objective: Create a character device driver capable of reading data from the harddisk while avoiding the filesystem's block cache.
  • The data read can be any consecutive blocks of data from the harddisk, does not need to directly correspond to a file on the filesystem.
  • Your character device driver should not rely upon any filesystem specific calls (such as fopen, open, fread, read, etc).
  • Your character device driver CAN rely upon the at_wini block device driver to read data from the hard disk.
  • Test Program Requirements: Your test program, benchmark.c, should be capable of timing how long it takes to read data from different sources. The three required sources are /dev/zero, /dev/<your_device>, and a regular file such as /home/testFile.txt. For each device being timed, average the read time of configurable size, M (i.e, 25 megabytes), with a configurable amount of loops, N (i.e., 10 loops).
  • *New 10/16* Documentation: Include documentation of what files you have modified, why you modified them, and how you implemented the project as a whole. Also include your testing process with any known bugs.
  • *New 10/16* Deliverables: You do -not- need to include the testFile(i.e, /home/testFile.txt) in your Sakai submission as that will be a very large file. You only need to include the source files you've modified (character driver), system.conf, benchmark program and program documentation.
  • Hints/Tips:
    
    1. Q: How do I make a character device driver?
       A: A pre-existing "hello world driver" exists in /usr/src/drivers/hello. This driver is already a character device driver and has all the base functionality you need for this project. Refer to Example 2 of this tutorial for more information.
    2. Q: What major number should I use for my character device driver with the mknod command?
       A: Any number higher than 20 is most likely safe. To check what is currently being used you can do "ls -l /dev" to check major numbers of devices.
    3. Q: How does my character device driver talk with a block device driver (at_wini)?
       A: This is a key component to completing Project #2. The Minix File System (MFS) in /usr/src/servers/mfs is already capable of talking with any block device driver. It uses a common library found in /usr/src/lib. If you are able to identify how MFS satisfies read/write requests(cached or not), it should be apparent what library is being used.
    4. Q: Where is the filesystem's block cache so I don't inadvertantly use it?
       A: MFS is the last device independent layer between the user's request and the device dependent block drivers. The caching mechanism is built into MFS and contained within cache.c.
    5. Q: I found the library MFS uses to talk with block drivers, but how do I talk to at_wini?
       A: The library must first be initialized with the devices you wish to communicate with. The initialization method takes a dev_t and string, the dev_t can be created using makedev(major, minor). You should use "at_wini_0" (verified for Minix 3.2.0) for the string parameter.
    6. *New*Q: How do I actually use the library?
       A: The best way to understand this library is to look at how MFS uses each function. If there is a function you don't understand you can run the following command: grep -r function /usr/src/servers/mfs | more. This will display all the files/lines that the function is being used in MFS so you can see examples of how to use it.
    7. *New 10/16*Q: How do I read data from a device for my benchmark program?
       A: To open up a device that has been brought on line with service up /usr/sbin/charDriver -dev /dev/test, you can simply use the standard fopen("/dev/test", "rb"), fread and fclose to interact with the driver. In Example 2 of the tutorial above, when you performed cat /dev/hello that is exactly what the cat command was doing.
    8. Hint: You should only need to modify your character device driver file, /etc/system.conf and test program. No other file within Minix requires modification.
    9. Hint: After any change made to your driver, before you launch it, make sure to type sync to flush any unwritten cached data to the harddrive. You most likely will crash the filesystem many times so sync prevents your changes from being lost!
    10. *New*Hint: Make sure to include the aforementioned library in your Makefile for your driver or you will get linker errors when you make your driver!

Helpful Resources

• Minix Resources:
  • Minix 3 Website
  • Minix Wiki
  • Minix Developer's Guide
• C Programming Resources:
  • C Tutorial