Table of Contents

CSC 4103: Group Projects

Here is a list of the course projects:

When due Project Project Type
Monday, February 17 Introduction to PintOS Individual
Monday, April 21 User Programs Group

In addition to these projects, we will ask you to work on a set of individual assignment. For more information on those, please see the corresponding page.

Programming is a skill best learned by doing, and the programming assignments in CSC4103 form the central skill development part of your experience in the course. We have a great set of assignments and projects planned that we hope you will find fun, challenging, illuminating, and rewarding!

Project 0 is an individual assignment while projects 1 and 2 are group projects. Projects 0, 1, and 2 are all part of the same course project designed such that any follow-on project requires for the previous parts to be finished successfully. The group projects are designed for a group of four students (in exceptional cases three students).

There are up to four assignments and up to three projects in total. Project 0 is designed to prepare you for the later assignments and practice your GDB ability, so it is intentionally much simpler than the remaining assignments and projects. In projects 1 and 2, you will extend PintOS in different dimensions and make it more robust and powerful.

In each project, we will release all the test cases to support your local development. After each commit, github will run the same test suite to grade your submissions, so don’t worry that your evil teaching assistant (TA) will intentionally design many corner cases only to deduct your scores.

In a word, we hope these projects will be a challenging but rewarding experience for all of you. If you have any suggestions, feel free to contact your instructor.

We recommend that you read the entire PintOS Documentation before you start working on any of the projects.

Cheating and Collaboration

This class has zero tolerance for cheating. We will run tools to check your submissions against a comprehensive database of solutions including past and present submissions for potential cheating. The consequences are very high. So do not cheat, do not cheat, do not cheat!

The basic policies for the project assignments are as follows:

  • Never copy project code or text found on the Internet, e.g., GitHub.
  • Never share code or text on the project. That also means do not make your solutions public on the Internet.
  • Never use others’ code or text in your solutions. This includes code/text from prior years or other institutions.
  • You may read but not copy Linux or BSD source code. You must cite any document or code that inspired your code. As long as you cite what you used, it’s not cheating. In the worst case, we deduct points if it undermines the assignment.

On the other hand, we encourage collaboration in the following form:

  • Explain a concept to another student, or ask another student to explain a concept to you.
  • Discuss algorithms or approaches for an exercise. But you should not exchange, look at, or copy each other’s code.
  • Discuss testing strategies and approaches.
  • Help someone else debug if they’ve got stuck. But you should not give that student code solution.

The course staff will actively detect possible ethics violations. For each project submission, we will run automated cheating detection tools to check your submission against a comprehensive database of solutions including solutions on the Internet, past submissions, and solutions from other institutions.

General Tips

You should read through and understand as much of the PintOS source code that you mean to modify before starting work on a project. In a sense, this is why we have you write a design document; it should be obvious that you have a good understanding, at the very least at a high level, of files such as userprog/process.c for Project 1. We see groups in office hours who are really struggling due to a conceptual misunderstanding that has informed the way they designed their implementations and thus has caused bugs when trying to actually implement them in code.

You should learn to use the advanced features of GDB. Often times, debugging your code usually takes longer than writing it. However, a good understanding of the code you are modifying can help you pinpoint where the error might be; hence, again, we strongly recommend you to read through and understand at least the files you will be modifying in each of the projects (with the caveat that it is a large codebase, so don’t overwhelm yourself).

These projects are designed to be difficult and even push you to your limits as a systems programmer, so plan to be busy and have fun!

Group work

In the past, many groups divided each assignment into pieces. Then, each group member worked on their piece until just before the deadline, at which time the group reconvened to combine their code and submit. This is a bad idea. We do not recommend this approach. Groups that do this often find that two changes conflict with each other, requiring lots of last-minute debugging. Some groups who have done this have turned in code that did not even compile or boot, much less pass any tests.

Instead, we recommend integrating your team’s changes early and often, using git. This is less likely to produce surprises, because everyone can see everyone else’s code as it is written, instead of just when it is finished. These systems also make it possible to review changes and, when a change introduces a bug, revert back to working versions of code.

We also encourage you to program in pairs, or even as a group. Having multiple sets of eyes looking at the same code can help avoid subtle bugs that would’ve otherwise been very difficult to debug.

We encourage each group to have regular meetings (e.g. twice a week) to make sure everyone is on the same page. In-person meetings are generally more productive, since people tend to be more attentive.

If you’re meeting through a call (e.g. Zoom), we recommend you enable live transcription. Moreover, you should take detailed notes during each meeting on a central document to reference back to.

Common questions about the projects

  1. What is the development environment for the assignments?

    In CSC4103, we write programs in the C language and use the Visual Studio Code IDE for editing, compiling, and debugging. Visit the Installation Guide for instructions on installing these tools on your computer.

  2. What is the expected project workload?

    There are up to three group projects (project 0 is an individual assignment), you typically will have four weeks to work on each. Each group consists of three to four students. Students self-report spending between 10 and 20 hours on each group project. If you find yourself consistently beyond the upper end of the range, please reach out to us. Our workload is challenging because we want to foster the most growth possible for you in our 14 weeks together, but we do want the total hours to stay within reason for a 3-credit course and can help find a strategy that works for you.

    All group projects consist of two parts: the design document and the final code submission. The design document is usually due at around the midpoint of a project.

  3. What is the policy on late project submissions?

    Students are granted a short grace period where we will accept late submissions without penalty. Read our course late policy for the details.

  4. What is the project collaboration policy?

    Our semester projects are team-based (three to four students). Please review the LSU Code of Student Conduct for general guidelines. Note that project 0 is an individual homework.

  5. How can we get help on our projects?

    Ask on our online Discord discussion forum and/or attend office hours. The forum is open 24/7 for discussion with your peers, and quick (though not 24/7, we do sleep!) answers from course staff. The instructor and TAs are available to answer questions after lecture and in weekly office hours.

  6. How are projects evaluated?

    Programs will be evaluated on “functionality” (is the program’s behavior correct?) and “style” (is the code well written and elegant?). All project submissions are constructed such that you will prove the correctness of your code by writing tests that are being automatically run on each submission to Github. Each submission will receive a detailed report on what parts were graded how and why.

  7. How do we receive feedback from our grader?

    You can view your submission on your github assignment repository with comments and annotations from your grader along with the scores for functionality and style. For some assignments, you will also meet with your TAs to discuss the grading feedback in a short “interactive grading” conference.

Table of contents