Notes on the pedagogy used in the OSC labs
From SOFTICE
|
This page aims at outlining the main pedagogical ideas that guided the development of these laboratories. More up-to-date information in available in our latest Publications and, more specifically, our recent submission to SIGCSE'2007 titled "New approaches for Linux-based undergraduate operating system concepts laboratories" (available on demand) and the "SOFTICE: Facilitating both Adoption of Linux Undergraduate Operating System Laboratories & Students' Immersion in Kernel code" EISTA 2006 paper's presentation slides.
Laboratories structure
These laboratories have been written with the following structure in mind:
| Briefing(s) | This section is the link between the lecture's concepts and the Linux kernel implementation. It is used to introduce the relevant kernel data structures and APIs |
| Solved | Pre-solved exercise(s) to help the students glue together the lecture and briefing concepts and techniques. |
| Exercise(s) | Analogy-based exercises which help student practice "hands-on" the concepts and techniques taught in the two previous sections. This complements the "passive" learning approach above and brings a more active learning component to the lab. The main objective is to define exercises that are close enough to the solved ones so that students can apply what they just learned. Progressively, more complexity is introduced to lead students through small, progressive, conceptual and technical jumps. |
| Projects | These are longer, more ambitious exercises which will force students to apply the training they got from the exercises while generalizing their knowledge to more challenging situations. |
Separating instruction from evaluation
One of the benefits of the above-mentionned structure is that it has been built from the start to help separating instruction form evaluation tasks. Exercises are not meant to be graded. This means that students can be encouraged to work in groups, seek "google" or other external help (forums, irc,...) and experience learning in a community as well as collaboration in study groups without the instructor needing to worry about cheating. This also enable the instructor to provide personal help as needed without raising concerns about the fairness of a graded assignments when different degrees of help have been provided to students.
To complement this learning tool, we evaluate students with individual assignments (the projects) for which external help is not allowed and instructors will provide less help along the way. Since the projects are built on the exercises, most of the questions can be answered by "did you understand exercise xyz?" and the ones that can't are generally the ones used to evaluate students' capability to generalize the acquired knowledge by themselves.
Problem with this system? Students tend to focus on graded assignments while dismissing non-mandatory ones. The solution we implemented consist in announcing from the start that projects (and exams questions) will be heavily based on the exercises. Some will be direct applications, some will be derivated and solvable by using analogical thinking and others will be generalized problems which will require a solid understanding of the corresponding exercises.
Pedagogical particularities of the SOFTICE approach
While Linux is a monolithic kernel, it features modularity through the Loadable Kernel Modules (LKM) concept. When starting an undergraduate OS course, students are often confronted to thousands of lines of code which overall structure they have to assimilate before to be able to start tackling problems and labs. This is certainly true for an OS as complex as Linux but also for educational OSes; five thousands lines of code take some time to get used to as well.
To make it easier and faster to get students started, the SOFTICE laboratories try to leverage the LKM modularity to introduce students to the kernel in a modular fashion. Each lab presents kernel data structures and APIs in a compartimentized manner.
Moreover, the perspective is not "how do I understand this huge code base?" but rather "how to I use this huge code base in my own programs?". This spells out the difference between teaching students how to understand and modify, to a certain degree, an OS kernel vs. teaching them how to program in kernel-space. Both approaches have potential, SOFTICE labs focus on the latter.
Last but not least, motivation. We introduced in some of our labs a security flavor which is there to offer students an opportunity to learn about OS kernels with a different perspective: "How can I abuse these data structures and APIs?". This mischievious perspective is generally more likely to tickle computer scientists curiosity and therefore bring further motivation while also building in students a nowaday necessary security culture. This culture, by showing them what the "bad guys" (used to) do, is expected to offer opportunities to introduce students to better programming practices while demystifying terms and techniques they will be exposed to in their carreer.
How to use these laboratories in your own course
These labs were written with flexibility of adoption in mind. Their 4-sections structure allows for different types of integration in existing courseware. Here are some obvious examples;
Closed laboratories
For this type of usage we suggest that the early material is reviewed and presented in class by an instructor (Faculty, TA) and the pre-solved exercises introduced as a live demo to the students. The instructor can then supervise the work on the analogy-based exercises and the final one.
Open laboratories
In this version, it is best for the instructor to provide hints about the laboratories at the end of his lecture. In the near future, more material (slides, ...) might be added to this page to help integrate the part of the laboratories introducing the kernel data structures in the lecture.
Integration as assignments in the lecture
Depending on the timing of the course, 3-4 laboratories can be used as take home assignments during the course of a semester. The instructor might want to make time in the lecture for covering the material and pre-solved material before to assign to students (or groups of students) the other exercises. Depending on the time available, the students can be refered to the readings referenced in our laboratories and simply be briefed up during the lecture on the most sailient features of the laboratories. We also recomend to assign and grade the final exercise of the selected laboratories while assigning as non-graded homework the analogy-based exercises. These allow for a review of the material and can be work on by groups of students with as much supervision and help as needed from the instructors while not causing academic honesty or grading-related problems.
