Operating Systems

Course Organization

The goal of the course is to provide practical understanding of common operating system features that impact application development - in particular the concepts of processes and the management of memory and processor resources available to processes, the support for concurrent execution, and the management of common devices. Towards this goal, the course combines lectures, focused on basic knowledge acquisition, with project work, focused on knowledge application. By the end of the course, you will have implemented your very own miniature operating system.

Self Study

To avoid wasting lecture time with rote fact dumping activities, lecture participation requires prior self study. The instructions for self study are available on the lectures page. Follow the instructions as you see fit - we fully expect you to skip those parts that you already know, obviously there might also be parts where you will need to look for additional background material on your own.

We will primarily refer to the book by Arpaci-Dusseau et al. called Operating Systems: Three Easy Pieces. This book is available online for free. Reasonable initiative is expected in looking up additional material, but the whole self study for one week should not take you more than one hour - if you feel that is not enough to understand the content, please bring your questions to the lecture for discussion.

Weekly Quizzes

To provide feedback on your progress, self study will be accompanied by weekly quizzes. The quizzes will be distributed as separate files in your individual git repository, such as 01-architecture-quiz.md. Please answer the questions by editing the file and committing it back into your repository by Monday 8:00 of the week before the actual lecture at the latest.

The quizzes are intended as formative assessment. We will provide feedback on each answer, however, whether your answers are correct or not will not impact your grade. The lectures will be dedicated to discussing selected material from self study in more depth, in particular where the quizzes reflect difficulties in understanding.

Note that you can ask your own question in the quiz and thus steer the lecture for your benefit.

Project Implementation

Independent of your self study activities, but synchronized so that the content required for implementation is studied beforehand, you will work on a project that will eventually culminate in a miniature but working operating system. Initially, you will work individually, but later you will form teams of three students to work on the project throughout the semester.

The project will constitute the summative assessment part of the course. It is split into features, further grouped into milestones, with specification handed out gradually throughout the semester. Each feature is either baseline or optional - as a bare minimum, your implementation must support all baseline features by the end of the course to pass, implementing baseline features on milestone schedule and implementing optional features improves grades.

The labs will be dedicated to introducing the project features in more depth and to providing appropriate technical support and feedback on code quality. Automated tests will also be provided for each feature to help with development and determine project progress. Note that the automated tests may fail to expose errors that violate the assignment requirements. Exploiting such situations to simplify solutions is considered cheating.

Communication

All communication, including the distribution of quizzes and project assignments and the submission of your work, will take place primarily through the course GitLab repositories. In addition to your individual repository, you will also have a team repository for team project work. There is also a forum repository for general discussion and issues that should reach us.

Please maintain reasonable notification settings for the individual and team repositories, new content will be pushed to those repositories with no other announcement.

We urge you to use the repositories to coordinate your team work. In particular, do commit frequently, and actively use branches, issues and merge requests with code review in your team. Apart from supporting your team, this also documents the team activity for us.

To identify formal submission of your project implementation for grading, we require that each such submission is associated with a repository tag, as described in the corresponding specification.

Grading Information …

… is on a separate page with all the information in one place.

Course Resources …

… are on a separate page with all the information in one place.

Exceptional Situations

The following rules for handling exceptional situations concern discretionary violations. Contact us if you think your situation deserves special consideration. As a rule, we expect to be contacted proactively rather than retroactively, unless your situation could not have been foreseen.

Late Quiz Submissions

Late quiz submissions (after the deadline for that particular quiz) will not be considered.

Late Project Submission

Late project submissions (after the end of the course) will not be considered.

Idle Team Members

Team members that stay idle for the duration of an entire milestone will be ejected from their teams without redress. Incomplete teams will be merged as the situation permits. Teams may arrange an alternative workload distribution with the lecturers.

Academic Integrity

The quiz work is individual, you should only discuss it with us. Using online documentation is fine, using ready made solutions is not fine, using feedback from artificial intelligence tools is not fine.

The project implementation is a team effort, you can discuss it both inside and outside your team. The code you commit can be both internal, written by your team for this year of this course, or external, written for another year or another course or copied from other sources.

External code must be clearly marked as such, using external code without attribution is considered cheating. If you decide to copy external code verbatim, state what part of your solution is copied and why. If you decide to transform external code into your solution, state what part of your solution was thus inspired and why. This also applies to code generated by artificial intelligence.

Please note that using large portions of external code means that you have not proven your skills of implementing an operating system and might affect the final grade (in extreme cases by failing the course).

When in doubt, ask us.

To avoid misunderstanding, here is a brief Q&A in the context of your first assignment:

Q: I found https://stackoverflow.com/questions/1735236/how-to-write-my-own-printf-in-c. Is it fine if I copy the answer ? A: No. The purpose of the assignment is to exercise your C coding skills. You demonstrate that by coding, not by copying.

Q: I found https://stackoverflow.com/questions/1735236/how-to-write-my-own-printf-in-c. Is it fine if I start with the answer and edit it into my own solution ? A: Maybe. If you are new to C, one way to learn may be to get the existing code and play with it, changing and debugging things to get an understanding of how it works. If you end up with code that is significantly different from the original, and you state your original inspiration, then the assignment fulfilled its purpose and we will understand how you worked when grading. But you should really take the code apart until you understand every bit of it, and then combine the pieces back into your solution.

Q: I decided to extend the assignment and included the ability to print disassembly with %pD using https://github.com/Mithreindeir/Dynzasm. Is it fine ? A: Sure, hope you had fun :-) did you remember to include attribution as required by the library license ?