The Project

Introduction | Mechanics | Getting Started | CHIP | HOCA


The project consists of designing and implementing the HOCA (Turkish for good teacher) operating system. The project is structured in three phases:

  1. The first phase involves implementing two modules that are later used in the nucleus to implement the process queue and the semaphore abstractions.
  2. The second phase involves building the nucleus --- the routines that implement the notion of asynchronous sequential processes, a pseudo-clock and the synchronization primitives.
  3. The third phase involves implementing another software level (the support level) that creates an environment with virtual memory, input/output devices and virtual synchronization operations that is suitable for the execution of user programs.


Project teams The project is to be done in teams of four or five. The assignments will be the same for either size team. Groups of five will have less coding to do per person but will also have to manage the interactions between more people. We will not allow teams of less than four. If for any reason you need to switch groups, you need to get explicit from the TA and instructor. In general, switching teams will only be approved effective after the current assignment is completed.

Journals Improving your engineering skills requires learning from your mistakes -- asking after each bug you find, ``how could I have found this bug earlier or with less effort?'' To encourage you to do this, every member of each group is to keep a journal of your activities in completing each assignment. The journal should contain which areas of the project you worked on, how you attacked each problem, and what bugs you found after you had gotten it to compile. The journals will be graded.
Also, in order to encourage every member of the team to contribute equally, every team member is required to individually email your TA with a quantitative assessment of the relative contributions of each of your teammates, excluding yourself. This should be turned in as part of your journal. If you have N people in your group, you have (N-1)*20 points to allocate among your teammates, proportional to how much they contributed to just this assignment.
It is our experience that for most groups, all of your teammates will pull their weight, and so you'll be able to simly give 20 points to each member. But if you have as teammates Sam Slacker, Annie Average, Hugh Helpful, and Connie Conscientious, for example, then you might allocate your 80 points as follows:

If on the next assignment, Sam starts pulling his weight, you should reflect his new performance (and not his past record) in the assessment for that assignment. We will use this information in determining final grades. By the way, many engineering companies use peer review to determine annual raises, so making your peers think you are useful is a good skill to have.

Grading policy The grading for the project will be as follows: 40% design, 30% comments and programming style, and 30% implementation. We have structured the grading in this way to encourage you to think through your solution before you start coding. If all you do is to work out a detailed design for what you would do to address the assignment (and if the design would work!), but you write no code, you will still get substantial credit. The implementation and code documentation portion of the grade considers whether you implemented your design, and provided documentation that the reader could understand. Part of being a good engineer is coming up with simple designs and easy to understand code; a solution which works isn't necessarily the best that you can do. Thus, part of the design and implementation grade will be based on whether your solution is elegant, simple, and easy to understand.

The intent of the grading for the project is not to differentiate among those students who do a careful design and implementation of the assignments -- in other words, don't implement some complex feature just because someone else in the class is implementing it. My expectation is that most of you will get close to full credit on each assignment. Rather, the grading is to help me identify those students who (i) don't do the assignments or (ii) don't think carefully about the design, and therefore end up with a messy and over-complicated solution. You cannot pass this course without at least making a serious attempt at each of the assignments. Further, the grading is skewed so that you will get substantial credit, even if your implementation doesn't completely work, provided your design is logical and easy to understand. (In other words, don't pull an all-nighter just to fix the last remaining bug in your solution.)

Grading: Design To be successful on this project without spending an indordinant amount of time on it, it is essential that you spend time designing a solution that will work before you start coding. To encourage this approach, half of the project grade will be based on your design of the system. The project design grade have four parts worth a total of 50 points per project.

Design proposal 5%
Design Review 15%
Code documentation
Journal 5%

Grading: Implementation Half of the project grade will be for your implementation. Each assignment will indicate how implementation points will be divided across different subcomponents of the project. The TA will compile and run your program and test cases. The TA may also run additional test cases that we devise! The TA will also evaluate your code's simplicity and elegance, as well as your coding style.

Grading: Teamwork For each project, your ``Teamwork'' score will be out of a possible 20 points. We will base this number on the average score given by your teammates, but the TA or instructor may adjust that number based on our interactions with you at the design review and at office hours or based on your journal. At the end of the semester, we will adjust your overall project grade based on your average ``teamwork'' grade on the projects as follows:

> 22 +1% to +5% of project grade
17-22 no change
15-17 -10% of project grade
13-15 -20% of project grade
10-13 -30% of project grade
7-10 -40% of project grade
5-7 -50% of project grade
3-5 -75% of project grade
0-3 -90% of project grade
0 -100% of project grade

Note that our goal is not to encourage anyone to take on huge amounts of extra work to gain extra credit at the expense of the rest of the team. And, as we indicated above, we expect the vast majority of students to do their fair share of work and get scores around 20 points.

Late policy We will use flexible slip dates for the assignments. Each team is given an automatic extension of 3 calendar days, which you can use on any assignment during the semester, in any increment, as long as the total amount of lateness did not add up to more than 4 days. For instance, you can hand in one assignment 4 days late, or each of four assignments 1 day late. This should let you schedule due dates around the due dates for other courses. When you hand in an assignment, you must identify at the top of the assignment, (i) how late this assignment is, and (ii) how much of the total slip time you have left. If you wish, you may calculate your remaining slip time to the nanosecond. After you have used up your slip time, any assignment handed in late will be marked off 10% per day or part thereof. There will be no extensions granted.

Getting Started

The project assignments will be done using public SPARC 5s. You can get a list of the machine names by typing cshosts pubss5. All upper-division CS students (which, I think, includes all students in the class) should already have accounts on these machines. If not, contact me.

In order to access the course software you should add the following to the PATH and MANPATH environment variables of your UNIX account:

You should also add the following to your .login file:

The CHIP Computer System

The Hoca Operating System