views:

380

answers:

9

I will be TA for an operating systems class this upcoming semester. The labs will be deal specifically with the Linux Kernel. What concepts/components of the Linux kernel do you think are the most important to cover in the class? What do you wish was covered in your studies that was left out? Any suggestions regarding the Linux kernel or overall operating systems design would be much appreciated.

+15  A: 

My list:

  1. What an operating system's concerns are: Abstraction and extension of the physical machine and resource management.
  2. How the build process works ie, how architecture specific/machine code stuff is implanted
  3. How system calls work and how modules can link up
  4. Memory management / Virtual Memory / Paging and all the rest
  5. How processes are born, live and die in POSIX and other systems
  6. userspace vs kernel threads and what the difference is between process/threads
  7. Why the monolithic Kernel design is growing tiresome and what are the alternatives
  8. Scheduling (and some of the alternative / domain specific schedulers)
  9. I/O, Driver development and how they are dynamically loaded
  10. The early stages of booting and what the kernel does to setup the environment
  11. Problems with clocks, mmu-less systems etc
  12. ... I could go on ...
  13. I almost forgot IPC and Unix 'eveything is a file' design decisions
  14. POSIX, why it exists, why it shouldn't

In the end just get them to go through tanenbaum's modern operating systems and also do case studies on some other kernels like Mach/Hurd's microkernel setup and maybe some distributed and exokernel stuff.

Give a broad view past Linux too, I recon

For those who are super geeky, the history of operating systems and why they are the way they are.

Aiden Bell
+1 on the monolithic kernel discussion
DoxaLogos
+1 I would also add driver development and kprobes...
LB
@Sweeny, MOS 3e is a great resource. The HURD stuff I would recommend as simpler source to look at for demonstrations. Or even MINIX.
Aiden Bell
@Aiden Bell The choice of OS is out of my hands. I understand your reasoning for suggesting to use a simpler source. The Linux source can be daunting at first, but thats what I am there for. I also want to encourage my students to continue with Linux development in the future in hopes that they will go on to fix bugs and give back to the community.
Sweeney
@Sweeney - I understand :) On a personal note, I think more people should get behind HURD -- I'm currently familiarizing myself with it to get involved.
Aiden Bell
There's a lot of stuff there, but it's good. Maybe also do something on file systems.
David Johnstone
+3  A: 

Well, I just finished my OS course this semester so I thought I'd chime in.

I was kind of upset that we didn't actually play around with the actual OS itself, rather we just did system programming. I'd recommend having the labs be on something that is in the OS itself, which is what it sounds like what you want to do.

One lab that I did enjoy and found useful however was writing our own malloc/free routines. It was difficult, but pretty entertaining as well.

Maybe also cover loading programs into memory and/or setting up the memory manager (such as paging).

samoz
+8  A: 

The Virtual File System layer is an absolute must for any Linux Operating System class.

I took a similar class in college. The most frustrating but, at the same time, helpful project was writing a small file system for the Linux operating system. Getting this to work takes ~2-3 weeks for a group of 4 people and really teaches you the ins and outs of the Kernel.

JaredPar
+1 for mentioning actually playing with the source
Aiden Bell
A: 

Memory mapped I/O and the 1g/3g vs 2g/2g split between kernel address space and user addressable space in 32bit operating systems.

Limitations of 32 bit architecture on hard drive size and what this means for the design of file systems.

Actually just all the pros and cons of going to 64 bit, what it means and why as well as the history and why are aren't there yet.

Jim Wallace
+3  A: 

For labs, one thing that may be cool is to show them actual code and discuss about it, ask questions about what do they think things are done that way and not another, etc.

If I were again in the University I would certainly appreciate more in depth lessons about synchronization primitives, concurrency and so on... those are hard matters that are more difficult to approach without proper guidance. I remember I went to a speech by Paul "Rusty" Russell about spinlocks and other synchronization primitives that was absolutely rad, maybe you could find it in youtube and borrow some ideas.

fortran
+1 on concurrency, although a distinction needs to be made about internal concurrency control and userland API
Aiden Bell
+1  A: 

The networking sub-system is also quite interesting. You could follow a packet as it goes from the socket system call to the wire and the other way around.

Fun assignments could be:

  • create a state-full firewall by using netfilter
  • create an HTTP load balancer
  • design and implement a simple tunneling protocol
tsg
+3  A: 

Another good topic (or possibly exercise for the students) would be looking at virtualisation. Especially Rusty Russel's "lguest" which is designed as a simple introduction to what is required to virtualise an operating system. The docs are good reading too.

stsquad
+1 ... in addition I would prime them on the classes of hypervisor and virtualization vs paravirtualization and how hardware helps.
Aiden Bell
+3  A: 

I actually just took a class that perfectly fits your description (OS Design using linux) in the spring. I was actually very frustrated with it because I felt like the teacher focused too narrowly for the projects rather than give a broader understanding. For instance, our last project revolved around futexes. My partner and I barely learned what they were, got it working (kinda) and then turned it in. I came away with no general knowledge of anything really from that project. I wish one of the projects had been to write a simple device driver or something like that.

In other words, I think it's good to make sure a good broad overview is presented, with as much detail as you can afford, but ultimately broad. I felt like my teacher nitpicked these tiny areas and made us intensely focus on those, while in the end I did NOT come away with that great of a general understanding of the inner-workings of Linux.

Another thing I'd like to note is a lot of why I didn't retain knowledge from the class was lack of organization. Topics came out of nowhere any given week, and there was no roadmap. Give the material a logical flow. Mental organization is the key to retaining the knowledge.

JoeCool
+3  A: 

I recently took an operating systems class, and I found the projects to be challenging, but essential in understanding the concepts in class. The projects were also fun, in that they involved us actually working with the Linux source code (version 2.6.12, or thereabouts).

Here's a list of some pretty good projects/concepts that I think should be covered in any operating systems class:

  • The difference between user space and kernel space
  • Process management (i.e. fork(), exec(), etc.)
  • Write a small shell that demonstrates knowledge of fork() and exec()
  • How system calls work, i.e. how do we switch from user to kernel mode
  • Add a simple system call to the Linux kernel, write a test application that calls the system call to demonstrate it works.
  • Synchronization in and out of the kernel
  • Implement synchronization primitives in user space
  • Understand how synchronization primitives work in kernel space
  • Understand how synchronization primitives differ between single-CPU architectures and SMP
  • Add a simple system call to the Linux kernel that demonstrates knowledge of how to use synchronization primitives in the Linux kernel (i.e. something that has to acquire, say, the tasklist lock, etc. but also make it something where you have to kmalloc, which can't be done while holding a lock (unless you GFP_ATOMIC, but you shouldn't, really))
  • Scheduling algorithms, and how scheduling takes place in the Linux kernel
  • Modify the Linux task scheduler by adding your own scheduling policy
  • What is paging? How does it work? Why do we have paging? How does it work in the Linux kernel?
  • Add a system call to the Linux kernel which, given an address, will tell you if that address is present or if it's been swapped out (or some other assignment involving paging).
  • File systems - what are they? Why do they exist? How do they work in the Linux kernel?
  • Disk scheduling algorithms - why do they exist? What are they?
  • Add a VFS to the Linux kernel
FreeMemory
Thanks for the feedback. These are good suggestions.
Sweeney