Class "Operating System"
While the students will be working on their own operating system during project work, the class itself also has an "Operating System" that defines the rules and policies by which the class tasks are scheduled and resources allocated.
Note: Due to SARS-CoV-2, we'll start the class ONLINE, and use QEMU for the first two milestones.
Materials and Hardware
This class uses the Toradex Colibri iMX8X platform for the course project. The students will build their operating system for this platform.
Toradex Colibri iMX8X: The students will receive their hardware kit
consisting of the compute module, carrier board, USB hub, SD-Card and two MicroUSB
cables in the first week's lab session.
The students must handle the hardware with great care.
Laptop: The students are expected to have access to a laptop for the course work,
and for demoing the milestones during lab hours.
The students are responsible to ensure working connectivity (i.e., USB A (all) and Ethernet (for the networking individual milestone)).
The course project assumes the latest Ubuntu LTS as the host operating system. All
instructions and examples use this assumption. All tests will be run on the latest
Ubuntu LTS. The students are free to use any other operating system, provided that
their submissions work on the latest Ubuntu LTS. The course staff will not provide
support for issues on any other operating system.
There is a Docker container that provides a compilation environment.
Code and Material Distribution: Source code and other materials (the course book, manuals, specifications, etc. ) will be distributed through a git repository. The students will use the provided git repository to submit their code and reports (see submission).
We will be using the discussion board for all project related questions and administrative issues. The students are expected to post course and project related questions there, and participate in the discussions. Note, this is not a competitive course, it is OK, even encouraged, to provide hints and answers to your fellow students they may do the same for one of your questions.
For personal matters and joker card requests, please send an e-mail to the course
instructors at achreto@cs
Use your UBC e-mail. E-Mails coming from non-UBC e-mail addresses will be ignored.
The final grade will be determined by the following criteria:
34% Milestone demos. These are the points awarded during the weekly milestone presentations. Individual milestones taken into account. The students are expected to demonstrate the required milestone functionality, explain the design and implementation, and answer questions on the milestone background.
33% Integration tests. These are the results of the integration tests run on the final submission. Individual milestones taken into account.
22% Final report. This includes the quality and completeness of the final report.
11% Final presentation/demo. How well the group did during the final presentation.
Extra Challenges: It suffices to complete the basic milestone requirements to receive the maximum grade. The students will be awarded extra points for completing the extra challenges, or finding and fixing bugs in the handout code base.
All milestones must be completed!
Grades will only be awarded after the student has returned their hardware kit.
Late submissions: Generally, submissions must be completed by the stated deadline. Late submissions will be graded at 75% (one week delay) and 50% (two weeks delay) respectively.
Joker Cards: Life happens, and sometimes it's good to get a little extra time.
- Each student will receive two joker cards that extend the deadline of individual milestones by one day each.
- Similarly, each group will receive three joker cards that extend the deadline of group milestones by one day each.
- The final hand-in deadline is a hard deadline and cannot be extended.
Presence requirements: All members of the group must be present at the milestone presentation and during the final presentation.
- May work together with another undergraduate student on the last individual milestone (except the shell)
- Weakest milestone grade will be excluded from final grade.
- Groups with two or more undergraduates can be up to 5 students in total.
Use of third-party libraries and code
This is not an algorithms course, or a coding interview. There won't be any points awarded for correctly implementing a self-balancing tree, or a solution based on dynamic programming. The students are allowed to make use of certain third-party libraries.
The use of third-party code (e.g., libraries, data structures, ...) must be approved by the instructor and properly cited in the report. Standard plagiarism rules apply.
In any case, all members of the groups must be able to explain the design and implementation.
The students agree not to publish their code on the Internet, or distribute it in other ways.
How to do well
Here we summarize some advice that may be useful to successfully complete the project.
To get most out of the lectures, it is highly recommended reading the next chapter in the book before the class. This enables an engaged discussion during class and to answer relevant questions.
The lectures are also your chance to ask questions about the next milestone early on in the week. So it's good to think about the upcoming tasks before the lecture.
Run on read hardware: While you can use the Qemu simulator for testing and debugging, the final tests and demonstrations will be run on real hardware, so make sure it also runs there.
Read the milestone descriptions carefully: are there any hints and explanations? What is the interface to be implemented? What is the required functionality?
Think before code: Think about the functionality that need to be implemented. Write down your architecture and keep design notes (this is helpful for your final presentation and your report). This is an important step, especially when you are working as a team.
Read ahead Each milestone will build upon the functionality of the previous one. So it's good to read a bit ahead and get an overview of the entire project.
Write tests: This is one way to make sure your code works as intended. This is especially important, as later milestones build upon earlier ones. Also, those tests will be a fantastic way to demonstrate your milestone.
Git Try to use version control wisely. Use meaningful and descriptive commit messages, and clean patches to help your teammates understand what you have done.
Each milestone will be demonstrated to one of the course staff. This will take about 15mins. The students will need to show that they have implemented all required functionality, and be prepared to answer question about their implementation, and on background material.
Write the report as you go, or at least keep notes. The students will be required to submit 1-2 pages of notes on their design decisions, implementation details etc with every milestone.
Make it entertaining and interesting, do a demo. What has worked well, what have you learned. What turned out to be a bad decision?