Computer Science Curriculum Using Linux?

I couldn't resist posting this question from Kris Warkentin: "I am helping a professor at my school develop some projects for a third-year Operating Systems course. I told him that Linux would be good for that sort of thing, both as an example and as fodder for development. It is a single term (13 weeks) and students in Computer Science, while competent, are not exactly experienced programming wizards like Alan Cox. So, the question is, does anyone know of any nice little Linux-based programming projects which would give a feel for the OS internals? Maybe some of you have actually taken a course where you wrote a device driver or something? Any ideas or suggestions would be welcome."

This is a real cool idea. Are there any other schools doing something like this with Linux?

real time linux

[vipw]

i'd suggest doing things with the real time linux kernel (rt-linux). While the student activity may not be directly benefitial to the linux movement, it is an understandable subset of the linux kernel which is designed to be easy to interact with from other kernel modules. besides the rt-linux project is important for embedded systems(an exploding market) and could definitely use a few more eyes.

this really isn't relevant

[vipw]

the question has more to do with what kernel projects students would learn more working with/on. what knowledge the students are able to take from the class is much more important that which programs they are familiar with. personally i dropped out because there was too much emphasis on familiarization with products than there was learning long-term programming skills.

use topsy or something similar

[Sultan]

at my university, the 3rd year introductory OS course uses topsy as the os background
and it involves writing such things as the
virtual memory handling as one of the assignments.

http://www.cse.unsw.edu.au/~cs3231/ [unsw.edu.au]

as it is now linux is probably too complex to be used, ie modified/improved on by most 3rd year students doing an intro OS course...

USB

[frederik]

Maybe you'd like to work at the USB drivers of the Linux Kernel. It needs some enhancement and I think the students would learn a lot by doing it ;)

freshmeat

[HomeySmurf]

Right on the main page of Slashdot, you will find a link to freshmeat [freshmeat.net] which list hundreds of open source projects of all types in various levels of completeness (sp?). They, of course, have a nice search feature, which is admitedly is not too great, but should do the job. Your professor should be able to find some project he likes there. It is also a great source of interesting code to analyze.

Sounds very different....

[DeadSea]

The course on Operating Systems I took at Cornell University had nothing to do with any specific operating system, or device drivers, or anything that I think it would really be easy to teach using linux. The only way I could see this working is by showing source code from the linux kernal as a real world example of how stuff as done.

We spent a lot of time working with the things that you would need to have programs running simultanously on a single processor: mutex, protected memory schemes, and such.

Maybe other colleges teach less theoretical OS classes, but I really don't see how it would fit in with what I took. (Granted after taking the coure I'm in no way a kernal hacker either, so there is probably a place for this somewhere...)

Process Manager

[Kamran]

In my university, we had to write a process manager, and add timeslicing, semaphores etc...
Some people had very little experience of C, so the program was split into smaller chunks. Although we didn't actually create the process manager as such, we learnt the basic algorithms for the process manager, using a text input file and output what would be run at each clock cycle.
You could also implement the Unix process priority system, giving priority to certain processes.

We also in the following semester created a virtual memory manager.

Good book for learning

[mihalis]

I would recommend looking into the book "Linux A-Z" by Phil Cornes. He starts off with an introduction to Linux for the complete beginner, but later on introduces neat little projects like Tiny Socket Library, Tiny Shell, Tiny Daemon and Tiny Device Driver. The writing is spare, accurate and elegant, and the book is even typeset (as far as I can tell) in Latex (love those computer modern fonts, just like the GNU manuals).

Of course the material might have to be updated a little here and there to make sure it doesn't lead the students down any blind alleys, but the beauty of the self-contained "Tiny" case studies is that they contain enough code to illustrate the principles being expounded - just tweak them a little if the system interfaces have changed and they'll still be great teaching material.

Chris Morgan

Minix may be better

[gbowland]

Minix may actually be a better choice. That's what Electrical & Electronic Engineering [uwa.edu.au] at The University of Western Australia uses in its operating systems course.

We also use Operating Systems: Design and Implementation (2nd edition) (Tanenbaum and Woodhull) as a textbook which includes Minix media and goes into great depth about the Minix OS.

The Linux kernel may not be as well documented for educational purposes.

Filesystem

[Tjl]

For relatively advanced students, I'd recommend writing their own simple filesystem.

For beginners, a new directory on /proc telling various things about the system state.

Or re-develop an existing device driver.

don't underestimate the students

[celticfiddleboy]

One of my OS courses involved loading BSD3.0 on a machine. The instructor gave us an overview of the internal structures and by the end of the course we had to make a significant modification to the kernel. The modification didn't necessarily need to extend the product in a meaningful way, it just had to interact with the kernel in a manner that demonstrated we had an understanding of the kernel. I.E. My project was to create a new FS that would encrypt/decrypt the data being written/read to this filesystem. Modifications were made to the utils such as mount to recognize the new FS and ask for passwords. The encryption algorithm was just XORing 1 to the data but the point of the exercise was not to design strong encryption but to show knowledge of the kernel internals. With Linux it would be easy to instruct the students on the structure of the kernel and how to extend it with modules. Have them write simple programs to drive printers through the serial port. Get them debugging kernel code. Once you are elbow deep in, new and more complex projects will present themselves such as different scheduling algorithms. Don't underestimate what the students might be capable of.

how about the alcatel?

[SquierStrat]

How about a device driver for the internal, or external USB Alcatel ADSL modems? :-) Would be kind of nice for those poor souls who were stuck with them by their evil ADSL provider.

Linux/MINIX

[mud_dog]

I'm currently taking an operating systems course in my 2nd year at university. The course uses MINIX as its example operating system. This includes using examples of how MINIX implements, say handling concurrent processes, in the leactures and also using MINIX as a base for the practical work in the course, although we don't actually fiddle with the MINIX code itself. I think that whatever OS you use in an OS course it is important to remeber that just studying that OS will not give a rounded a view of how OS's work. Rather the implementation of the OS studyed should be used as a getting off point to also look at the many alternative ways in which OS features can be implemented.

Theory vs Practice

[Ayrezyle]

When I took my 3rd year CompSci OS course, we used an OS called Oberon on which we implemented the minix filesystem for a stiffy drive (University of Stellenbosch, South Africa, 1998).

This was only the practical component. It was totally disconnected from the theory for which we used a (good, IMHO,) book by Deitel .

I liked the theory but not the OS (Oberon; you think linux has interface blues!?!?). Which in turn meant I liked the theory but not the practicals. However, I was exposed to both teory and a real life OS with it's own design decisions etc. which was open for me to analyse and critisize. Going back to the theory then meant I could match the decisions made by the designers with the tradeoffs, benefits & penalties explained in theory.

I think linux (or a scaled down version of it) is an excellent idea for CompSci practical work. Especially because of the Open Source nature and the *nix introduction it offers.

Prof.'s Objections are weak.

[Martin S.]

Possibly the Prof.'s problem is that by choosing an open OS such as Linux over some obscure proprietary system, they could very easily be trumped by there students?

The scope could be readily limited by confining study to the Kernel and since Linux (the Kernel) was written AFAIK as a finalist project, I'd say that a study of the Linux is an excellent idea for a 3rd Year computer science Operating Systems course.

I certainly wished I'd have had that opportunity :) because I had to study Op'S's without source. This was too theoretical; there should be room on a CS grad course for both theory and practice of such an important subject.

Linux would be great for comparing the theoretical ideals against practical compromises, an area where CS grad's (including myself) are traditionally weak, and since the first step in doing a task properly is understanding, given a little time could pay dividends for Linux as well as the grad's.

Try Minix :)

[GaiJin78]

At our school we use the book "Operating Systems, Design and Implementation" by A.S. Tanenbaum, which discusses the basics of OSes, taking Minix as an example. Minix is a very narrowed Unix-like OS with the basic features in it, such as I/O, file system handling, threads, and more OS related things. An idea maybe?

Re:Sounds very different....

[Peter Eckersley]

I tutor OS here at the University of Melbourne. We also have a primarily theoretical course at 3rd year, and then a 4th year course which goes into great and messy depth on the implementation of 4.4BSD, but stops short of visiting any actual code. The 3rd year course does however include some projects on implementing abstracted cache and disk scheduling algorithms. The 4th year course could perhaps be Linux-ised by using one of the LDP kernel books.

I agree that I can't see the point of cutting real-world code instead of doing this kind of course. *But* - once you've actually done that, you might want to move into playing with the real linux kernel. Don't start your own project unless you come up with a brilliant idea (like implementing an rsync [anu.edu.au] based network filesystem :). Instead, go and find an interesting project (like USB, ReiserFS, or CODA) and work on that...

OS/2 is better...

[ltning]

...for seeing the OS internals. The OS/2 kernel is built around all the best schoolbook examples there is, except perhaps for the scheduler which is far ahead of anything else.
Besides, the device driver interface is quite easy to understand, and well documented, giving close relations to the kernel/hw at the same time as being logical and pretty straight-forward.

Good luck!

My Projects

[sPaKr]

At my school we are using Linux for our OS class now. We tweeked the RT scheduler , and added a new type instead of just FIFO, it was similuar, but did allowed jobs to be prioritezed before they started excuting. Starting with the proc entry was a good place to get going from. The device Driver was also a very good project. The device driver we impletmted was just a message queue. IE a /dev/msg entry where you would open the device, write some string, and it was stored in the kernel, Then reads on the device would return the messages in the same order. Good Project. For the final project we are working on a file system. They dont think we can code well enough so its all similuated in user space, but hey Im gunna wedge into the kernel cause thats just uber cool. I would also recomend groups of 2 students, try and give 1 - 2 weeks for each project, and then do the filesystem last, give 4 weeks, and make it kernel space.

Don't use linux

[Anonymous Coward]

Have you actually _looked_ at the kernel sources?

It's quite unapproachable. Not because the things that are being done there are particularly complex, but it's all over the place and almost completely undocumented/uncommented.

Sorry to say, but the lack of documentation and plain simple comments is caused by laziness, arrogance and selfishness. This will detract from the usefulness of Linux because people such as yourself will be driven away. It will reduce the size of the developer community and will _of course_ reduce the quality of the product.

This will only get worse as it's going from a simple singly threaded model into a much more parallel design. There is NO SUBSTITUTE for carefully documenting your locking strategy. The designer's intentions cannot be practically reverse engineered from the source and without a clear understanding of the locking strategy the only people who can effectively maintain and grow it are the original authors, as long as they remember what they were thinking at the time.

And who can we blame for this situation apart from he-who-waddles-on-water?

- Anonymous Linux kernel developer.

NachOS...

[mitch_wagner]

During my last term I took Intro to Operating Systems we used a set of source code from berkely and washington called nachos. It basically emulates a MIPS 2000 platform. It is set up to have around 5 or 6 projects. Multithreading, File systems, Multi-processing, Memory Management and others. There are ports of the code for BDS, Linux, Solaris etc.... I suggest you go here for ideas. http://www.cs.washington.edu/homes/t om/nachos/ [washington.edu]

a few suggestions

[dana]

Here are some of the things I've enjoyed doing
as school here at Concordia (the university in
Montreal)

Writing a simple shell with support for pipes
and i/o redirection.

Writing a simple server-client applications (some
kind of echo or file transfer client)

Writing a program to dump a file to stdout by
reading the disk blocks directly.

Writing a rudimentary undelete for ext2.

Using semaphores to solve simple multi-thread
problems (one writer-may readers, cars on a bridge
etc)

IMHO, a number of smaller projects is more useful
than one large one because the students can find
what they like and then can maybe expand on it later when they become open source contributors. :)

Just look at any part of the system and ask "I
wonder how that works" and voila, a project will
hatch out of that slowly.

Good luck!
Dana

Take one specific section and research it.

[Durrik]

Back in the days when I was a third year university student our professor had us look into either Linux or BSD for a specific section and research it.

We then had to write a mini paper on how it worked and give a presentation to the class so that the rest of the class got a good look at how these other areas of the kernel worked.

I only remember the following topics of the ones we were told to research:

Inter Process Communications
Device Independent I/O
Task management (process switching)
Memory Management (with swap space)
File management (main filesystem)
Device management (drivers for network, scsi, etc)

There was a list of 20 or so topics, and a team of three could pick one of them for either Linux or BSD.

I'm not sure what a class of college students will be able to do to help with kernel development. After all, your average college student isn't a kernel hacker, and you're not going to have an entire class be able to contribute. I'd say only a handful of the students in the class would have the ability, time, or the interest to contribute to the kernel, and that's not fair for the rest of the class who paid to learn the theory and the knowledge to develop the ability.

Anyways when I took the class, Murry Goldberg at UBC was teaching it. Just look up CPSC 315 and 415 at UBC, he's usually open to questions.

Re:real time linux ... maybe for grad students?

[Sun Tzu]

Wouldn't Minix (or, perhaps, a very early Linux) be better for for most educational (kernel work) purposes? Linux is getting kinda large and, generally, that means that it gets harder and harder to extract the concepts from the code.

I would think that a highly modular (read: totally unoptimized except for clarity) small kernel system would be vastly superior for most educational use. Note that I understand that, at the highest levels, there is no substitute for studying reality in all its complexity. But most of education involves building to that level and LInux is a big chunk.

As for non-kernel work, which the questioner seems to be suggesting, I imagine Linux would be perfect. You would only need to look at particular pieces of code when your device driver behaves unexpectedly. That the code is there and royalty-free is a huge advantage. That the code is solid and well tested is priceless. ;)

Just finished a course like this.

[Anonymous Coward]

I just finished a course like this. We used RedHat
5.2 (with a nice, relatively simple 2.0.x kernel
that reduced the learning curve a bit). We had two
kernel programming assignments:

1) Add process scheduling groups.
We added a couple new system calls that allowed processes to create and then join new
scheduling groups. You could set priorities for group member processes and then any time one
member of the group came up, the highest priority TASK_RUNNING process in the group would
be selected to run instead. This lead to pretty useless behaviour but didn't involve anything
other than adding to the scheduler, so you didn't screw up the behaviour of non-group-member
processes.

2) Add a new in-RAM filesystem to the kernel.
We had to add a 128K in-RAM volatile (your data disappears when you unmount the fs) filesystem to
the kernel. This was nice because you didn't have to create any user-space tools (other than
your own version of mount). When you mounted one of these filesystems the kernel allocated
128K and created your filesystem on it. You could mount as many as you wanted and use them
just like any chunk of disk space. This was a great way to learn the basics of Linux' rather
cool VFS.

Neither of these projects was hugely difficult but
they weren't trivial either. We also had to write
some basic kernel functionality benchmarks and
compare Linux 2.0/Sparc (our systems) vs. some
Solaris/UltraSparc systems. That was interesting
as well. This was a great course, so long as you
liked alot of programming.

Linux for Computer Science?

[kd7ahv]

I think using Linux would be a good use of student's time and effort. I am a Comp Sci/Electrical Engeneering major(s) and I know that if I was to be given a programming project, I would want it to be somthing that was useful. Device drivers, processor bug workarounds, hardware interaction fixes, anything to improve the way that the OS works. I personally would rather work on a class project that had lasting value, than one that was simply "do this, do that, file it away and work on what's next" I have too many of those already.

Re:Don't use linux

[HeUnique]

Well, thats true - many developers don't really comment what they write.. But if you want Linux kernel with comments, then check this [amazon.com] at Amazon [amazon.com]

Princeton OS course

[Mahy]

I don't know any details, but I know our OS course uses Linux. I guess you could check the web page, here [princeton.edu]. Check under last semester's course listings.

Project listing site.

[rew]

I would recommend setting up a site where users, professors, kernel developers and students can enter projects.

Then you have to get people to enter projects in the database, which can be done by different types of students: Small assignment for an OS course: small projects. Graduating projects: larger projects.

With a bit of hacking, jitterbug could handle this kind of job nicely. Professors wanting to "sort" requests to directories that they approve or disapprove for a certain assignment, can be given an account on jitterbug.... (The hacking is required to allow different professors to have different ratings for the projects)

Roger.

A shell is a good start

[sstrick]

A uni we had to write a shell that supported programming structure and conditional statements. It also had to allow pipe commands, input and output redirection and wildcards.

It was not to difficult but it was challenging enough for a then inexperienced prorammer to have to really think. It also leaves the person that wrote it with a very good idea of shell scripting and what you can do in it.

Re:THE MODERATORS ON SLASHDOT ARE SMOKING CRACK

[Chuck Chunder]

Oh yeah, there's thousands of operating systems listed on Freshmeat. In fact there's so many it's difficult to find user level apps there..........
The 'on crack' moderators are the ones who mark the original post up after your protest....

Re:Don't use linux

[MeanGene]

Have you actually _looked_ at the kernel sources?

It's quite unapproachable. Not because the things that are being done there are particularly complex, but it's all over the place and almost completely undocumented/uncommented.

Great! Make the first assignment to write comments for some stable parts of the kernel - then submit patches to the tree! :)

comment from a 3rd year CS student

[rongen]

Hi, I'm a 3rd year CS student. I think an OS class (especially an intro class) should focus more on IPC, mutual exclusion, and exploring different models for partitioning user and kernel space, etc. While Linux rocks, there doesn't seem to be any reason to focus on it specifically. All OS designs should be looked at, contrasted, and critiqued. CS students need to learn general principles (that is one reason why you take CS instead of attending a "career college").

Also, when it comes to programming assignments, it might be good to encourage slightly portable code. Maybe making sure your application compiles on both Linux AND Solaris (or whatever you are using). This can be a good experience. I can think of a few times where execvp or whatever behaved differently on these two systems and kept me up late learning why (I looked everywhere but that function to figure out why my program was hanging on Solaris and running fine on Linux).

Re:NachOS...

[dirt]

I'd like to second that. Currently I'm enrolled in an OS class using nachos (here at UW), and though many of us talk disparagingly about it (nobody likes grueling coding sessions under a deadline), I've found it well-designed and very flexible.

The only caveat of a "fake" (i.e. simulated) OS is that you can make a number of cheats that you wouldn't ordinarily be able to do in a "real" OS (e.g. you don't really have to fully re-execute an instruction on a page fault within a syscall -- just fault it in and continue); also kernel data structures don't really exist in the simulated machine's physical memory. There are a lot of smaller issues too, like the use of C++, some people disagree with their coding style, etc.

But really, that's not relevant to understanding the concepts and implementing them. The code that they give you is enough of a head start that you can actually learn relevant material rather than cutting hundreds of boring, potentially buggy, lines of code.

---

Why limit the project to Linux?

[mhunter]

There are three kinds of operating systems courses: those that teach no practical applications at all (useless), those that teach some useful fragments without providing a broad overall view, and those which force the student to implement an entire, useable operating system by the end of the course.

Clearly Linux is only really relevent to the second type. If you want to learn about OSes properly, as in a structured set of assignments, you're better off doing the whole thing yourself, rather than focusing on one piece you are actually implementing and leaving the rest in the realm of theory.

Doing "something serious and new" with the Linux kernel makes a great MS or Phd thesis, however.

A course at Yale

[PrimeEnd]

A course at Yale does something quite close to what you are describing. They use Linux as the programing environment, but produce a baby standalone operating system. It looks very interesting.

Take a look here. [yale.edu]

Oh. You wanna *start* w/an OS?

[aheitner]

in the Carnegie Mellon operating systems course (mostly taken by juniors/seniors, tho it isn't specifically a "3rd year" course), you don't start with any operating system.

The course is taught on SPARC emulators, which run on (you guessed it) SPARCs and make the architecture a bit more manageable. But you write the operating system ... that's kind of the point :)

It's not all that complex an operating system, nice and straightforward and unix-ish, but it's a hell of a lot for one semester. The course is done in project groups, and it has a reputation as about the hardest class out there.

I've had friends in the course get back after a week almost exlusively in the lab. They show up friday afternoon in a zombie like state...
--"What did you write this week in OS?"
--"Huh? Oh, inter-process data streams. You know, pipes"
--"Neat"
--"pipe pipe pipe! pipe! PIPE! PIPE!" [nervous sobs]

my os course....

[j1mmy]

The OS course I took last quarter mostly had us writing programs to simulate OS operations. We worked with the pthread library to get a better understanding of processes and thread, wrote scheduling simulators to build on that, and did a few things under NT like developing a cmd-like shell.

This quarter we basically just progressively built a filesystem driver for FAT12, but it didn't really relate to the lecture material and took far too much time for most students.

I suggest you stay away from actual kernel hacking, at least until later in the course. Simulations are less dangerous to the system, especially when the students are coding in an area they have little to no experience with. As per my second point, make sure the assignments are relevant and not too long.

Unix can also be used

[Lothar]

I know this is off topix but it is obvious that both Unix and Linux is good for teaching Operating Systems.

Writing a simple device driver is one of the assignments which could be given to the students. Maybe one could have groupwork and look into creating a simple kernel module for Linux.

The problem is to get the staff to avoid underemestimate the students. When I was taking the class "Operating Systems 2" at Strathclyde Uni(Glasgow - Scotland) , what we used was Sun workstations and we only had to use pipes, multiple processes, threads etc...patethic :(. It was all very simple and nobody taught us anything about the kernel.

Re:Don't use linux

[Periwinkle]

Maybe what they need to do in thier class is write *Documentation* (gasp!!) for the Linux kernel. Or at least those parts that haven't made it into some book yet. The linux kernel is constantly under development, I'm sure there's always something new to document here and there. And it sure would be useful.

-John
I eat dog. Free DVDs [opendvd.org]. Horray!

Some Thoughts ...

[trexl]

Some time ago, I took my CS Operating Systems class and there was an accompanying lab. The two were disjointed (I really didn't like it, but both courses became easy A's). The course proper dealt with theory, just like the post a few back. Mutex and protected memory, spin locks and dining philosophers ... The lab consisted of attempting to do very basic OS type operations, but used NT. Since there were'nt enough NT boxes in the lab, some of us that worked were forced to "BUY NT"(the horror, not so much NT, but BUYING IT). I told the professor that I didn't have the means to do so and to his credit he accepted linux/unix versions of equivalent projects for the NT assignments. I attempted the NT, but found that for even an NT fork() there were about 10 parameters to be passed. Most were for the GUI and could be eliminated, but there were about 3 that weren't. I was completely confused. fork() doesn't need parameters.

What I learned from this approach is that operating systems should be taught at both levels, theoretical and practical. The theory and practice should coincide, and that OS theory has little to do with window placement, border sizes, and adding these things only confuses students. I guess the final thought in all of this is that it is best for an OS class to use an OS based on the theory that it teaches, *nix, Linux, a BSD or derivative so that the theory blends best with the practical. Using a Free OS just makes it easier on the students, especially those that can't make it to the lab all day because they work.

Redo existing stuff.

[stripes]

At the University of Maryland we wrote an extreamly primitave OS (no filesystem, no memory protection, but it had a text mode windowing system!). We did it from the raw hardware, so it was pretty damm chalanging. You learn a lot of things that way (like how to really write intrrupt handlers, not how to use someone else's framework!).

I think there is a lot of merit in that approch. It was the only class at UofM where we touched bare metal (the assembly class was close though). I think it is important that CS students do that at least once.

I also think students could benifit from doing larger things to an existing OS. But as a diffrent class. I would focus not on things Linux needs, but things the students could learn from. Like putting in a fixed-priority scheduler, and then testing for priority inversion, and finding a way to fix that. Maybe adding a batch scheduler. Writing a driver for a simple piece of hardware (like the serial port). Maybe something slighlty more complex, like something that DMAs. Maybe an IDE controler driver. Sound cards would be better then IDE controlers, except that would be a pain in a lab enviroment, and the hardware changes from year to year.

I know none of this would directly benifit the Linux comunity, but it would greatly benifit the students. Remember it is easyer to grade a project with a known outcome then something open ended! It is also easyer for the TAs to advise students on smaller projects with known results. The students will gain some first hand knolage of formerly abstract concepts, and some knolage of Linux internals.

Reading Kernel source code; Filesystem

[jlrobins_uncc]

When I taught our (UNC-Charlotte's CSCI) graduate operating systems course [uncc.edu], assmuming that the students had already received an undergraduate OS course (sadly, sometimes too hopeful of an assumption) which covered the core basics of memory management, process management, context swtching, and introduces the two-layer device driver approach (our undergraduate course uses the XINU book), I picked up where that course left off, covering more about device drivers, I/O descriptors and their interaction with system calls, the filesystem (on-disk implementations, kernel implementations, different implementations at different mountpoints), then finishing off with distributed systems. One large component of the course was reading the Linux kernel source code in order to see a "real world" implementation of the coding concepts discussed in class. I have aways been a critic of how too many CSCI courses focus solely upon writing projects, yet don't spend enough (or any) time having the students read non-trivial code. We wouldn't ask novelists-in-training, essayists-in-training, or poets-in-training to write more than we've asked them to read, would we?

Anyway, two series of projects accompanied the lectures and assigned code readings. The first was to design and implement a basic interactive shell, first with basic file redirection and piping, later adding redirection to TCP sockets. This project aimed at giving the students a taste of systems programming that they may not have otherwise received, plus hammering in the UNIX concept that read() / write() will work on any sort of descriptor, be it pipe, file, or socket; even without the knowledge / cooperation of the process doing the I/O. At the time of writing the projects, the students were to read though the kernel code which implements the major system calls that they were using in order to see what was really going on (or at least to get a general idea that it all wasn't magic -- it all boiled down to "C" source code somewhere).

The second project suite was the implementation of an inode-based filesystem, starting from the ground up. First write a simulated mini-SCSI bus that supported two types of devices (one with 512-byte sectors, the other with 4096-byte sectors, just to ward off assumptions at the inode/block management layer). Once that works, add an inode manager that can use one of the virtual SCSI disks. Lastly, add a directory services module on top of the inode manager, so that we can manipulate files, directories, and symbolic links.

Ultimately, the projects asked a good deal from the students, as that the majority of them had not written any multi-threaded OO systems that made use of message passing (over the SCSI "bus"), so not only did they get to simulate some kernel components, they also had to come up to speed with some relatively advanced programming designs. The folks who used C++ learned the hard way that (at the time) debugger support for multithreaded programs was, um, challenged. Folks who wrote in Java had a bit of an easier time. Depending upon the level of knowledge in your undergraduates, I would not recommend the filesystem project. The shell project, OTOH, would be applicable to either 3'rd/4'th year undergraduates or graduate students, as that it hits home on the core UNIX datastructure -- the I/O descriptor. If the students were to have root access to the boxes, then I would have them perhaps extend an existing kernel subsystem or to write a new driver given an existing one. What about a thorough examination of the Linux scheduler / context switching algorithm. Could they cut any fat from it, as the IBM JDK folks did? What about examining the timer system? What about implementing a new "toy" virtual device driver, such as /dev/random (not that it is a toy, but that it doesn't correspond to any single piece of hardware, per se), such as a simple message passing port? One process opens it up, writes to it, then closes, followed by another process opening it and reading from it. That would demonstrate upper-layer device driver interfaces, plus the issue of passing bulk data to/from user space, and why time spent memcpy'ing becomes a factor in I/O bound systems.

Oh yeah, one other thing. You might want to think about obtaining the source code for more than one OS kernel (say also a *BSD kernel or the Solaris kernel -- being at an institution of higher learning, you should be able to get the Solaris source code w/o charge) in order to have the students compare / constrast the different approaches taken.

Have fun with the course!

Re:My Projects

[Yelskwah]

Are you perchance at Stafford? This seems almost exactly what we had to do for OS years ago when I was a second year. Basically (without giving away what you're supposed to do) we had a version 1 linux lab and had to modify the scheduler so as to bias a certain profile of process. We were using version 1 because the rt scheduler was manageable then, I think in V2 it kind of started taking steroids and acquired all the SMP functions. Is Phil Cornes still at Staffs?

Re:Oh. You wanna *start* w/an OS?

[ralphclark]

That's what I like to see. If the students aren't crying, they're not working hard enough! I'm mostly serious about this; between 1985-1995 there was a steady and continual deterioration in the quality of CS graduates (I've not done any recruiting since then so I can't speak for the last 5 years). And those graduates don't half get a shock when they enter the world of work and see just what level of effort and skill is expected of them. It benefits no-one to dumb down Computer Science courses.

<blockquote>Cram it in, jam it in
The students heads are hollow.
Cram it in, jam it in:
There's plenty more to follow</blockquote>

Consciousness is not what it thinks it is
Thought exists only as an abstraction

Distributed computing architecture

[Yelskwah]

I should probably add that as finalists on the Distributed Computing Course we were tasked with building a load-balancing system which would take a process and run it accross the system, returning results when the process ended. I think I solved it by having a daemon run on each box which would serve the box load and accept incoming processes. A master daemon would take new processes, find the lowest-loaded box and send them off. The process itself was linked against a library of functions, one of which organised for the process to be moved to the least-loaded box. The problem was the process had to be network-aware. Moving arbitrary user-space processes requires various kernel structures be unhooked and moved too (not within the project scope). It worked pretty well; it was nice (in a geeky way) to have the lab to onesself occasionaly and to hear the process migrating around the room (disk activity gave it away). When the process ended, the distribution daemon on whatever box it was one would send its output back to the master. I'm a little hazy, there may have been more daemons involved and I don't want to dig out my coursework (I promised the psychologist never to look at it again :)

Linux? Nah, start simpler.

[britt]

In my OS class (and at other schools like UC Berkeley, Duke, and Harvard) we used a package called NachOS [duke.edu]. It runs on a MIPS emulator, and you write large chunks of the OS yourself. We had to write processes, system calls, filesystems, VM, schedulers, applications for the OS (the shell was just 5% of assignment 2). The final assignment is to write a couple different schedulers or other subsystem, then performance analyize the hell out of it, which was really interesting.

Granted this course has a reputation for being WICKED hard. The whole OS is multi-threaded etc etc, so you have to deal with all the fun race condition issues just like a real OS. Running on a simulator makes life much better for a couple of reasons. 1) crash/rebuild/restart/debug cycle is MUCH FASTER. 2) debugging real kernels w/o having two machines (for serial debugging) is not fun, plus you've got to have the machines for the students, which can be a pain. 3) come on, device drivers aren't the _interesting_ part of the OS, so using a system where thats already done is more useful.

I liked doing this better than what other people here have suggested. I think just writing a device driver is kinda silly. It's a reasonably straight forward project, not really a good thing to do in an OS course, having students working with all the important OS components is much more useful. Starting with Linux is not a very good idea because of the large code base, and from what I've seen it's not really the best code for students to read. I would recommend one of the BSDs if you really want to go with the whole OS paradigm, especially FreeBSD when McKusick comes out with "The Design and Implementation of the FreeBSD Operating System." A second OS course or a Graduate level one is a better place to have students dive into a real OS, at that point you know the background theoretics of OS work, and you've written a fairly large code base of your own. Then it becomes much easier for students to dive into a real OS and do some research.

For books I'd say the Tanebaum book (already mentioned here) and the 4.4BSD book are very good.

Re:Don't use linux

[Yelskwah]

You're right, but although I don't expect professionals to leave their code uncommented and undocumented, it still *is* that way in a lot of cases.

Back where I worked last, the support organisation wouldn't accept code for maintenance until it had gone through at least one code review to check maintainability. If it wasn't maintainable, it went back to the developers until it *was*. There was an incentive for the devlopers to do it right first time as they didn't get grief from their managers for making the handover late and being over budget.

Re:Oh. You wanna *start* w/an OS?

[britt]

Ah yes, Harvard's OS course is like this as well. Average assignment is about 50+ hours of coding a week...

Page Fault TWITCH Spawn TWITCH MIPS assembly TWITCH

There's nothing like spending 15+ hour stretches in the lab looking for that one Heisenbug in your VM system...

Learn fundamentals

[drnomad]

In my computer science class we typically did some small projects on producer/consumer problems. If I were you (or your proffessor) I wouldn't pick an open source project for teaching.

You will be working with existing code from guys who have absolutely more experience than you (like you said, you're not really masters of programming). It will take an awfull lot of time to get into the code and understand how it works.

When I was at college, they tought me the basic principles. Well it is an OS-course, so learn OS-things. I worked with Unix/Minix and some other stuff, but you could use Linux.

Try this book for fundamental problems with producer/consumer problems, semaphores and dining philosefers problems: "Operating System Concepts" by A. Silberschatz, J. Peterson and P. Galvin (ISBN 0-201-55793-2 or ISBN 0-201-54873-9)

This is a good book for teaching. In my RedHat installation, there were several pthread examples which demonstrate consumer/producer situations, why don't you try it with processes instead of threads, then you must work with that awfull 'fork' command, something very common to Operating Systems (not MS-DOS! ;-) ).

Have fun!

NACHOS is a fantastic learning OS

[raygundan]

We are using NACHOS at Purdue University, and it beats the pants off of starting with something as complex and "finished" as Linux. NACHOS is a simple OS that is designed to allow students to implement VM, Scheduling, Mutual Exclusion, Filesystems, etc... It is easy enough to undertand that we just dove right in and started coding, rather than working on little isolated examples first. I highly recommend it.

Re:Oh. You wanna *start* w/an OS?

[coondog]

I would agree that OS at CMU is a killer course. However, I do think that it is incredibly beneficial to have completed the projects that are in the course: a simple shell, a tty driver (that uses mutual exclusion to make sure multiple writes / reads are not interleaved), a simple kernel (context switching, virtual memory mapping, IPC, semaphores, fork, exec, etc), and a simple file system.

I do think that any CS major who has a chance to take such a course should take it. It provides you with an amazing amount of experience for one semester.

You can check out the course web page at http://www.cs.cmu.edu/~412/ [cmu.edu].

CS Curriculum...

[AlexZander]

I am a CS Student at WPI and as a requirement for EVERY CS class I've taken but one, the program's are all targeted for Unix / Linux. My Operating Systems professor spent a long time talking about linux in the course, which I found fascinating!

Use solaris

[StanSmith]

Computer Science studies at the university level are still not focused enough towards helping the student find a job afterwards. Well, neither are any other sort of studies at a university, but CS has less of an exuse in my opinion.

I have a close friend who graduated with a CS degree, and knows nothing of Unix. I constantly find myself glancing sidelong at him, asking 'what exactly the fuck did they teach you at that college?'.

Teach on Solaris. Businesses use it, and you'll be doing your students a favor. Linux is fun, and free. If your students have the love, they'll go home and teach Linux to themselves.

Re:Oh. You wanna *start* w/an OS?

[Muad]

I seem to ermember that students at Stellenbisch University, near Cape Town, do build their own OS during the second year - but they do that under Oberon. Still, it is a remarkable achievemnt....

In my university, Boston College, it depends on the professor teaching the course. I know a professor used to require teaking Minix, but the current trend seems to be writing a scheduler for Linux, although the problem is not really tackled at system level.

BTW: our CS lab is 60% RedHat Linux, 40% WinnNT.

One word: NACHOS ....

[opencode]

Stands for Not Another Completely Hueristic Operating System ....

It's essentially a bare-bones OS skeleton, that is highly-customizeable, in the sense that every student in a class of 25 will write different algorithms ....

There's a standardized "four-phase" curriculum used world-wide, and each phase has 8-12 projects (most are more design-oriented than code writing) ... fun stuff ...

Sure, it's used pretty heavily in graduate OS studies; but who's to say younger students can't "analyze" the system calls, file systems, and virtual memory constructions ...

http://www.cs.duke.EDU/~narten/110/nachos/main/m ain.html

Hacking some OS can be good for students to know

[stoev]

Implement/append/make better some of these.

http://www.infowar.co.uk/thc/files/thc/LKM_HACKI NG.html

http://www.infowar.co.uk/thc/files/thc/slkm-1.0. html

http://www.infowar.co.uk/thc/files/thc/bsdkern.h tml

http://www.infowar.co.uk/thc/files/thc/anonymous -unix.html

Note: This IS very important for people in CS. This is the real life and advanced stuff in the same time. CS will need to understand this in the future.

Re:Minix may be better

[DJStealth]

In my school (Ryerson Polytechnic University in Toronto).. Our primary operating systems are Linux and Solaris.

The 3rd year Advanced O/S course is based using Minix (yes, this is where linux came from) and one of the projects is to develop a memory manager for the O/S.

Re:Don't use linux - good point

[*borktheork*]

After reading the Tanenbaum book, I decided to tweak some things in the kernel (just for the hell of it) - this became a long-term project to actually understand the code. Comments? We don't need no stinkin' comments! - Well, actually there are a few comments, mostly dating back to pre 1.0 versions...

BSD

[howardjp]

No, really! Even though I am not well versed in kernel design, just flipping through the FreeBSD kernel code will teach you quite a bit about how the system works at a user level. The Design and Implementation of the 4.4BSD Operating System is an excellent resource to have handy when learning to program at the user level in Unix. If you use it, you will have a far greater understanding of how the kernel and libraries are handling the calls you make and you will quickly understand programming more.

Class Material

[HerbieTMac]

I TA'd an OS class for professional-level students last year called Operating Systems. We used the Tannenbaum & Woodhull text "Operating Systems: Design and Implementation." Students were asked to use Linux for their programming OS and I used RH for my examples. The main programming assignments for this course were:

• Write a pipe program to redirect output from one program to input for another. (i.e. pipe program1 \| program2)
• Write a program to share a memory page between two processes created with the fork() system call.
• Using semaphors, write a program to solve the dining philosophers problem [uci.edu].

This was a 10 week course. Most of the programming was used merely to augument the topics covered in the reading and lectures. Additionally, each student was required to turn in a final project consisting of either a functional program which added value to the operating system (and was released under GPL) or a final paper describing the functionality of one of the 5 main parts of an OS.

Take a look at ELKS

[sdaemon]

Take a look at ELKS, the Embeddable Linux Kernel Subset, aka Linux-8086. Its an attempt to port a subset of linux to the 16-bit processors of the 8086 family. The kernel is small enough to be understandable by developers who haven't been with the project since day 1.

It's being done already here..

[Pizza]

Here at Georgia Tech [gatech.edu] They're experimenting with such a concept in a Junior-level OS class.
CS3210 [gatech.edu] I was almost involved with the course but I ended up having way too stuff on my plate aleready this semester. Alas, as the course looks extremely interesting.

Anyway, check it out!

- Pizza

Re:NACHOS is a fantastic learning OS

[UberThread]

I agree -- here at the University of Michigan, we are using a slightly modified version of Nachos. At first glance,it is rather complex and confusing. However, it's **nothing** compared to Linux; my partners and I have peeked at the source code for Linux for reference. Although Nachos has given me countless days/nights of anxiety, I [grudgingly] admit that it provides students a "nice" way to implement fundumental OS concepts such as interrupts, [preemtive] scheduling, synchonization (with both semaphores and monitors), priorities, system calls, exception-handling, file systems, etc.

Re:Just finished a course like this.

[jandrese]

Frankly I'm amazed at the number of schools here that assign projects in kernel-land. I know the lab admins here would have a fit if someone assigned projects that required the students to not only have root access, but to mess around with the kernel.

Here, when they teach OS, the first thing the students do is write an emulator for a system, then implement the various projects on top of it.

Serial Drivers

[DrStrange]

From what I have found, writing a serial driver from scratch is about the easiest device driver to write. It also can be written using a polling or interrupt based method so you'll get experience with both. Anything more complex would probably take more time to write from scratch than it would be worth in a class.

WSU

[maz!]

At Washington State University [wsu.edu], a combination of MINIX and Linux is used for the operating system class [wsu.edu]. You may start something out on Linux, move it to MINIX where you make it work for your OWN operating system. That is, you boot your OS from floppy.

MINIX is used because it is easier to write an OS in it.

here's exactly what you want

[mikek]

Here at Columbia there is a course exactly like that where they study operating systems and all the programming projects involve modifying a linux kernel. The book even discusses linux as one of its case studies. The book is:
Operating System Concepts, 5th edition, Abraham Silberschatz and Peter Baer Galvin, Addison Wesley,Reading, MA, 1998.
You can check out the course website at http://www.cs.columbia.edu/~w4118/ [columbia.edu]. Just so you know I haven't taken the course yet. I'm taking it next semester, but I knew about it through friends and the professor. I hope this is useful.

Re:My Projects (Good Books To Teach With/From)

[Carnage4Life]

Linux Kernel Internals 2e Beck, Bohme, Dziadzka, Kunitz, Magnus, Verworner Addison-Wesley 1998 480 pages ISBN 0-201-33143-8

Linux Device Drivers Rubini O'Reilly 1998 421 pages ISBN 1-56592-292-1

Linux Core Kernel Commentary Maxwell Coriolis Press 1999 575 pages ISBN 1-57610-469-9

Applied Operating System Concepts 1e Silberschatz, Galvin, Gagne Wiley 2000 840 pages ISBN 0-471-36508-4

Ten projects for your OS class.

[Black Parrot]

Well, OK, I can only think of five right now. Someone help me out here.

5) Integrate your favorite browser into the OS.

4) Detect and warn if DR-DOS is present.

3) Add theme support for BSODs.

2) Provide a back door for UCITA remote disables.

1) Hide the NSA key.

p.s. - We need an HTML tag for reverse-numbered lists!
--

Re:Oh. You wanna *start* w/an OS?

[six11]

I worked on a project with a guy a couple semesters ago who was graduating. He did exactly zero work for the project, and even missed the final presentation because he was busy at Sun getting interviewed. I was a better programmer/computer scientist than this guy was when I was a freshman, and sun hired him. That really made me optimistic about the future, knowing what sort of morons I was, um, competing with.

Re:Use solaris

[be-fan]

You do realize that learning UNIX is not essential to having a CS degree. People can be master programmers without ever having touched UNIX. There are many reasons, but the main ones are...
A) Everyone uses Windows. Face it, a deep knowledge of Win32 is much more usefull than a deep knowledge of UNIX in the commercial application world.
B) The Win32 is easier to learn and has more coherent resources. Sure the UNIX APIs have much more documentation, but the books put out by MS give a pretty good overview of the entire API.
C) CS degrees can also be in algorithms and programming techniques. In that case it doesn't matter what OS one uses, becuase most calls will be standard C or C++ library calls.
D) CS degrees can also be in computer graphics, in that case windows is the best OS to use because it has the best hardware support for graphics APIs. And if your programming so low level that you're not using OpenGL or something of the sort, then your probably using DOS.
Just because many people use it in the CS field doesn't mean its the only way to go. DOS is probably the best for beginning level CS courses, and for application design, BeOS is probably best because its API is so easy to use. For scientific and other hardcore stuff, UNIX is probably the way to go.

Minix would be "better" for a 13 week course

[Anonymous Coward]

HI, Having gone through such a course myself in the past two years, I can say that Tanenbaum's Operating Systems paired with it's minix cd (version 2) is an excellent way to go. There are versions for the PC, Sparc, and one that will run ontop of Solaris (Very nice if your're messing with the scheduler .....) Projects we did included: writing ps for minix writing top for minix re-writing the process scheduler to be priority level based The key point about minix/the book is that their scope is just about perfect for the time given; not to broad, not to little and enough similarities to Linux to get people interested for your new grad level course

Re:Some Thoughts ...

[be-fan]

Actually, don't critisize NT for having fork() take parameters. NT was designed for threading from the ground up, and fork() and some of the other POSIX stuff doesn't mesh to well with it. Its a problem in general for systems that aren't POSIX at the core, I know BeOS really doesn't like forks() and once you use one, you lock yourself out from using BeOS threads.

Something involving concurrency ....

[taniwha]

Make sure there' something involving interrupts, timing holes/windows, multiple CPUS etc etc

My experience has been that the thing that programmers find hardest about kernel work is learning how to think about how things interact in time - ie non-sequentially - I spent 5 years unix kernel hacking for a living and even for the really experienced people I worked with this was something they had to think hard at to get right - it never seemed to become they just understood intuitively. Now after 10 years as a chip designer it's become 2nd nature.

Also make sure there's something to do with cache coherency - learning where the right places are to flush the cache (and not to do it too often) when 2 concurrent things are communicating (a dma controller with a driver for example) - this is something that requires a good detailed understanding of the hardware that's underlying the system

Nachos

[akiaki007]

I am currently taking an OS programming class and we're using a very simple broke down OS created JUST for this purpose by UC Berkely [berkeley.edu].

Nachos [berkeley.edu] prior to your modifications is a very very simple OS. Originally you start with the threads section and modify their code in order to show problems with Concurrent Programming. Then you show the proper way to do programming and create Semaphore, Locks, and Condtion variables, and your own special Synchronization Primitive. After which we program a Building with N Elevators with N people. This is half the semester, and I don't remember what we're doing after this, but we went as far as creating our own memory/process manager/allocator.

This is quite a fast paced and intense class. Difficult...yes...worth it, I'm sure.

Stay away from drivers

[gelfling]

In the real world it's the bottom of the food chain and you are tied to a specific vendor.

Re:Minix may be better

[Erk]

Here at the University of Maine [umaine.edu], our Operating Systems course (COS431) [maine.edu] everything is Minix based. It gives you a good handle on how system calls are implemented, mutex, and more.

Our project involves building a complete operating system titled Brain2k. Part I of Brain2k is building a VM which handles specific operations, and file I/O. Part II is a process scheduler allowing 10 seperate Brain programs to run simultaneously. We haven't gotten to Parts III or IV yet.

As for our book, we are using Operating Systems by Tannebaum. It's a pretty good book, uses lots of examples like the Dining Philosopher's Problem, and more.

If you have more questions, please email me!

linux schminux

[Anonymous Coward]

the course is about OS theory not "linux" linux is an example of an OS, just like microsoft windows, and you have no business 'pushing' linux into a class just because you like linux any more than microsoft has any business 'pushing' profs to use microsoft.

Re:Minix may be better

[wct]

I took this course last year and have to agree that for educational purposes Minix is a better choice. A strong point in it's favour is that you have an excellent textbook with an (almost) full source listing, so you can study the actual code while reading the textbook. The other advantage is that Minix implements the described OS algorithms in the most straightforward possible way. A beginner would be confused sifting through the Linux source when faced with the various assembler optimization tricks and hardware workarounds in there to speed up performance, and this detracts from the basics you're trying to teach.

The other major factor I think of that favours Minix is that the codebase is completely stable, and has been for a long time. While it may have been at the root of the dispute between him and Torvalds [kde.org], Tanenbaum's insistence on keeping the feature-set small enough to run on legacy hardware has made the code much more easily navigable and instructive. Having said that, comparing and contrasting the two would be valuable towards an overall understanding of the topic.

The only thing annoying about Minix is that it didn't run under VMware at the time (v1.0), so when programming kernel patches you had to resort to using bochs in the code-test-debug cycle. Setting up bochs at home was a real pain, and it still ran painfully slowly.

I don't think there is any book that fully documents in detail the workings of the Linux kernel like Tanenbaum does Minix; the rate that the kernel is evolving probably makes this a futile exercise. I do recall a thick book in the University library that covered the workings of a BSD kernel (NetBSD?), which would be handy in a course such as this, but not the title :(.

Just random thoughts :)

Re:Just finished a course like this.

[hal313]

I am currently in a 300 level OS class. Our projects comprise of simulations of OS components such as file systems, memory management and process management. Though not specific to any platform or OS, we do have a SUN lab (but I still use Linux). The programs that we write comprise more or less of an emulated component. For instance, the file system we write resides in memory (unless I add a feature to write the memory contents to a hard file). The cool thing is that we get to design our own file system, adding the features that we like from real file systems. An advantage to emulating the file system is that it reduces the burden of me having to figure out how to physically write to the hard drive (and quite possibly break it). My file system project is due Tuesday, by the way, and I am not quite done ;-)

Minix! (sp?)

[Hynman]

Our book came with the source code to minix. I asked my OS Prof about linux and he said it was too complicated for a 14 week course. Looking at the source though, minix looks ideal for this kinda course.

My experience...

[Malc]

Andrew Tanenbaum: Modern Operating Systems, Prentice-Hall.

This is a very good book for introductory Operating Systems.

I learnt one of my programming strengths from Tanebaum's book: multi-processing/threading (experience in the real world has lead me to believe most people have no clue when it comes to programming concurrent code). After taking an OS course, people should be able to describe a solution to the Dining Philosopher's problem (I used to ask about this when conducting interviews of potential new hires, explaining it for those who weren't familiar with it - I was shocked by how many people couldn't deal with it). Every program I right these days has concurrency issues. My course taught this through a thread package that abstracted threads to their base concepts without getting into operating system specific implementation details (it incidentally ran on Linux). Getting bogged down with an operating system's implementation details just causes confusion in an introductory course, making it more difficult to learn the base concepts.

The last project of the course was a bit more specific, and involved writing a mini-shell for Linux, with some of the c-shell functionality (commandline parsing, sychronous and asynch program execution, etc). But by then we were familiar enough with the concepts that we ready to try doing it for real (although a lot people were still able to bring down the Linux boxes by eating up the process table).

My advice: work though Tanenbaum's book, which will explain the most important OS concepts: stressing fundamental issues in design, process management, memory management, synchronization, interprocess communication,, file systems, shared resource management, etc. Then on the practical side, base the assignments on concurrent programming. This takes time to learn, it's best/only learnt through experience, and is a critical concept to understand.

My experience/advice...

[Malc]

Andrew Tanenbaum: Modern Operating Systems, Prentice-Hall.

This is a very good book for introductory Operating Systems.

I learnt one of my programming strengths from Tanebaum's book: multi-processing/threading (experience in the real world has lead me to believe most people have no clue when it comes to programming concurrent code). After taking an OS course, people should be able to describe a solution to the Dining Philosopher's problem (I used to ask about this when conducting interviews of potential new hires, explaining it for those who weren't familiar with it - I was shocked by how many people couldn't deal with it). Every program I write these days seems to have concurrency issues. My course taught this through a thread package that abstracted threads to their base concepts without getting into operating system specific implementation details (it incidentally ran on Linux). Getting bogged down with an operating system's implementation details just causes confusion in an introductory course, making it more difficult to learn the base concepts.

The last project of the course was a bit more specific, and involved writing a mini-shell for Linux, with some of the c-shell functionality (commandline parsing, sychronous and asynch program execution, etc). But by then we were familiar enough with the concepts that we ready to try doing it for real (although a lot people were still able to bring down the Linux boxes by eating up the process table).

My advice: work through Tanenbaum's book, which will explain the most important OS concepts: stressing fundamental issues in design, process management, memory management, synchronization, interprocess communication,, file systems, shared resource management, etc. Then on the practical side, base the assignments on concurrent programming. This takes time to learn, it's best/only learnt through experience, and is a critical concept to understand.

Follow this link for the thread package [carleton.ca] that I learnt from (Carleton University, Ottawa, course 95.300). It runs in Linux, it's light-weight, it's simple, it helps with learning the concepts.

Why only in college?

[Rares Marian]

Given the Debian team is mostly in their mid teens, they're perfectly capable to learn this stuff.

Complicated OS. . .

[JohnZed]

Hmm... I'd have mixed feelings about using Linux for this sort of class, because I'm a big fan of hands-on learning. And, if you think about it, writing a device driver isn't much like designing a whole OS.
Around here, our OpSys class uses the Tannenbaum book (which includes lots of samples from Minix, a simpler OS that was designed for teaching purposes). In small groups, students then implement most of the major OS subsystems (memory management, file system, boot loader, etc), while being given code for some of the more dull things (i.e., the shell, although I did just have to write a job control shell for another theoretically-second-semester class and it was a boring $%!#%). The cool thing is that, at the end of the semester, you have a floppy disk with your own primitive OS on it.
--JRZ

Re:Oh. You wanna *start* w/an OS?

[ElitistWhiner]

The greatest lessons I learned in CS circa 1974 were the weeks spent in the lab writing code through the night. This would go on without any indication we'd have something to hand-in that was running on Friday.

Courseware was given out on levels. If you couldn't get level1 grokked step down to an easier level2 assignment. By Friday there would be only a couple of us left grinding level1.

The lesson was that level1 while requiring more knowledge, was the easier assignment if you understood the problem. It demonstrated the power of abstraction and using the right tools for the job.

I went back to an Ivy League CS program to brush-up mid90's when I had some time. I was shocked curruculum changes had reduced a CS education to assignments out of the back of the book. All the challenge and creativity seemed sucked out of the program. Profs. admitted that they had sold out and were churning out C++ programmers for Industry.

It saddened me that these kids couldn't get the rush of knowledge acquisition and insight from the challenge of creating their own solutions. There was only the back of the book problem set and one possible solution set.

More than cram it into their skulls, challenge the curriculum with innovative problem sets that students can bring their own intelligence to the solution. If there exists only one possible solution set... there is no incentive to experiment and challenge their intellect.

Re:Use solaris

[JohnZed]

Computer Science studies at the university level are still not focused enough towards helping the student find a job afterwards.

Thank God! If you leave college with a strong background in programming and theory (even if you mostly just know C/C++ and Linux or Unix), I mean, one that covers theory of large-scale programming, OSes, and especially algorithms, you'll have a long-term base that will last you even if we all end up progamming in some bizarre, currently-unknown lagnuage on 3-dimensional displays running on BeOS 9.12.

Why? Because, if you know your stuff, you can always pick up a couple of books or take a quick training class (cost: $100 - $2000 ) to learn the newest industry trend. But if you don't learn the theoretical, university-style fundamentals, you will most likely never learn them, and go through the rest of your life as a fairly mediocre programmer.

In particular, it's scary that I've met people who graduated with nothing more than a series of "Programming in X, level Y" classes. A friend of mine intereviewed someone who came from a curriculum like that, and asked him to write "strlen()". The applicant (a VB programmer) thought about it, then proceeded to write a program that repeatedly split a given string in half until it ended up with only one character, then counted the number of splits it took. Wow.

You can learn "skills" any time. Use your university time to learn theory, if you want ot get your money's worth!
--JRZ

What about the HURD?

[kzin]

Linux is pretty much finished now, so finding new things to do can be
either hard or give you a feeling that you're not doing "real
work". But what about GNU HURD? It's a work in progress right now,
needs a lot of help, and is a microkernel, which is a much more modern
design. How about contributing?

- Adi Stav

Re:Oh. You wanna *start* w/an OS?

[Capt Dan]

I took the CMU OS course as a junior all those many years ago... And I must say that it was quite possibly the most educational CS course I have taken.

As aheitner posted above, it runs using specialized emulatorsm not to make the architecture more manageable, but as a sandbox or virutal machine for the OS you are writing.

When I took OS, there were 3 projects:
1) write a basic priority based scheduler. Time: 2 weeks, solo project.
2) Write a kernel. Time: 6 weeks, solo project. In reality it took three weeks of constant coding. We implemented ISR's, memory management, fork, exec, wait, sleep, read, write, malloc, and another 10 basic OS functions I cannot remember. I wrote a kernel.
3) Complete Filesystem. Time: 4 weeks, with a partner. We wrote a complete filesystem

The projects varied depending on who the professor was for that semester. The other semesters projects were all partner oriented which allowed them the time to do things like terminals/shells and kernel threads.

I do not understand why people are looking for projects that tweak the OS itself, or add to it. I learned so much about OS and about myself and my abilities by having a 6 page project spec dumped in my lap and being told "here ya go. Have fun. You have the TA's office hours."

It's like learning to drive a car. Sure there's a manual that you can study, and you can sit in the drivers seat for a while and play with the blinkers and the wind sheild wipers while going "vroom! vroom!" but unless you have someone force you to learn to drive, you'll never know how good your skills really are.

Talking about advanced capabilites in an OS course is all well and good, but save it for grad courses. An undergrad course should be about the kernel and basic resource management.


"You want to kiss the sky? Better learn how to kneel." - U2

What UC Berkeley Does...

[bifrost]

Currently, they teach a lot of computer theory with BSD based systems. A lot of the campus infrastructure runs with FreeBSD, and the fact that the CSRG was started there and Kirk McKusic teaches there sorta helps that along. Reviewing FreeBSD kernel code is easy because its clean, fast, and it makes sense. I've read through a few other Kernels and none of them made as much sense as the FreeBSD kernel did, maybe it shows bias, but I know quite a few people who feel that way.
Every time I read through Linux source, I have to grep to find things, its pretty imposing.

Re:real time linux ... maybe for grad students?

[Zurk]

not really. linux may be large but all the drivers are really small. complexity is great to learn from and its not that hard. it took me two weeks to write a barebones driver. i'd recommend a fairly simple project that illustrates some important concepts for this sort of thing. maybe a small kernel based timer to drive an external application of some sort, a small filesystem driver, a small network driver for a crude serial port network device or something similar. the palmpilot is a great help to hook up via the serial ports or a small serial terminal with a small microprocessor which can be programmed to simulate various simple system concepts and/or hardware interfaces.

Re:Oh. You wanna *start* w/an OS?

[wik]

Not to mention the fact that the embedded course is A LOT of fun (at least when my project demos actually work!). This semester the final project may or may not happen, but in previous years it consisted of writing code to record from a QuickCam and microphone in real-time on a small ARM7-based system and playback the video/audio streams later. Not a trivial task.

Right now we're coding up Tron on a terminal to get the basics of concurrency. This is the stuff that I grew up wanting to do when I was a young stupid kid with an IBM PC. The cool thing about this class is if you get really mad at something, there's a physical board that you can kick. Not that I'd ever do that... :)

Re:Oh. You wanna *start* w/an OS?

[ralphclark]

I certainly sympathize with that. Even when you have a lengthy resume behind you, and even when you're being interviewed by a manager with some technical ability, the criteria by which the final selection is made often seems to go more by chicken guts and the phases of the moon than anything *real*. That guy must simply have an interviewing style that was suited to the interviewer.

BTW, watch out for programming syntax tests. I've been to numerous interviews that could only be passed if were able to parse the most hideous abortions of C syntax in your head under pressure. The fact that no sane person would ever write such a statement or declaration is neither here nor there, it seems they just want walking talking K&R books. Programming style? Irrelevant. Readability? Who cares. Ability to map a problem to a solution? Not important.

And they wonder why so many software projects fail...

IMO if you're confronted with this sort of thing during an interview it's best just to politely decline and leave...unless you'd enjoy working for a clueless project manager alongside a horde of incompetent spaghetti coders.

Consciousness is not what it thinks it is
Thought exists only as an abstraction

There's a project mill out there just waiting

[xant]

And it's called sourceforge.net. If you're looking for "small" projects, have your students shoot out there to sf.net, pick one or more projects that are personally interesting to them, find the project's "TODO" list and implement a few features for the sf team. Turn in the before-and-after source, explain what the feature was and how you implemented it. Would require a modicum of oversight by the professor beforehand so he could make sure that everyone's project was about the same complexity and amount of work. Sourceforge even contains hierarchically categorized lists so you could channel your class into a specific category of application or problem depending on the particular class or module you were in.

If even one university put this sort of class project into operation the open source community would benefit tremendously. Imagine: instead of having a new flavor of mp3 encoder coming out every day, students could all pick their favorite and make it better.

And I don't think I need to tell you that this would be an important learning process for CS majors today, given the open source revolution we seem to be in the midst of. Writing the code is important, but learning the CVS model of development has real-world implications (even if you go to work for a commercial software entity like I did). Any coder can sit down and knock off a simple program from scratch; it takes real knowhow to learn how to work with and leverage other people's code.

Re:a few suggestions

[TeknoDragon]

MINIX MINIX MINIX! aka DIY Operating System

Some of the core cirriculum here at <a href="http://www.eecs.wsu.edu">WSU</a> is Comp. Sci. <a href="http://www.eecs.wsu.edu/~cs360/">360</a> and <a href="http://www.eecs.wsu.edu/~cs460/">460</a>. As you can see from the web pages (check out "project specifications") you basically write a minix-liek OS here. In 360 you learn fundamentals of unix and get to code a shell, filesystem, and file management stuff. In 460 you do the rest of the fundamentals. When I took 360 last semester there wasn't any of this NT Visual Studios BS. Oh well, they move with the times and students here start using MS Dev Studio from 250 on... it's probably one of the few MS producs that I am satisfied with

360 and 460 sound like the coures that somone posted down below about "here at CMU we... blah blah blah we're so great blah blahhhh..." but really you can probably get the same thing from any CS department in the top 25, so don't put yourself in too much debt getting there! [arrogant voice] here at *WSU* we use cheap ass Pentium class processors and learn x86 assembly, screw your commercial unix... practically all our labs run linux now[/arrogant voice]

Dr. Wang kicks butt, so does Hagemeister, Rounds, and probably a few I haven't taken. There are some really tough proffs that teach theory too (one is my advisor). Who just about drive students MAD, but now that I'm getting up in the cirriculum to where I can start to consider going for my MS they really don't seem that bad... they just happen to be bad teachers and a bit too demanding for most people's tastes...

check out the comp sci requirements <a href="http://www.eecs.wsu.edu/web_main/programs/pr ograms.html">here</a> if you're interested in any of the other classes and where they fit in.

Linux is too complex for a learning OS

[geggle]

I believe that Linux would probably be too complex for use in an introductory-style OS course. Perhaps we are missing the point here - OSes used in teaching courses should be a) simple, b) easy to modify and c) allow investigation a selection of concepts, without having to know it all at once. They are not for contributing to Open Source success.

In my undergrad OS course we used some funky custom-built thing on PDP-11/03's (Oooo... those front-panel switches :-). When I left University, they were using Minix. Perhaps something else has come up since then, but I can't convince myself that it is Linux.

Have you played with the NU for windows?

[Taco Cowboy]

I agree with what you said, that NU for DOS is not needed.

But I am NOT talking about NU for DOS. I _am_ talking about NU for windoze.

Have you played with the latest version of NU for windoze?

You'd be amaze how many things they have there. Some of those things are _seriously_ needed for Linux.

And I am not joking.

Re:Oh. You wanna *start* w/an OS?

[ralphclark]

Ah, but the sad thing is that I'm not just talking about interviews for junior positions but those for contract programming roles earning £100K per year. Most programming roles are maintenance roles, but most maintenance doesn't just entail one-line changes, there's still a degree of design involved. And even a one-line change can be fscked up.

Consciousness is not what it thinks it is
Thought exists only as an abstraction

Re:Use solaris

[be-fan]

>>>>>>>>>>>>
My experience says otherwise. I know patch-installing, MS Dev subscribing, hands-on Windows MCSE/MCSD gurus who can definitely be said to have a deep knowledge of Win32. But that's it. Win32. One set of APIs. The Microsoft-centric way of doing things. "Click on these wizards here and it will do it all for you" kind of programming. Of course when it comes to having to digging down to the bones to find out what is going on - perhaps to solve a difficult problem - they're clueless. They don't have the source to the OS so they can only make educated guesses at best as to what might be going on. >>>>>>>>>>
Thats a pretty sad group of programmers then. The problem is that you believe that sterotype that all Win32 programmers use app wizards. Some do, mainly hobbyists, but I know that in circles of serious programmers, even using something like MFC is frowned upon. Most can dig down into the roots to find a difficult problem. The 3D studio MAX guys could probably whip 99% of the Mesa or KGI guys when it came to graphics code. If you're talking about less serious programmers (like most Linux programmers are) then yes, maybe they do use MFC and app wizards. Windows is a fundementally different paradigm from UNIX, especially Linux. Most apps that ones uses in Linux are made by people who do it on the side. On Linux these people have to use the low level code, but on Windows they'd probably use app wizards. On windows however, you're mostly running apps from major developers, who hate MFC and app wizards.
Second, I never said that windows was properly documented. For the course of a few years of college training however, you're not going to need anything more than Petzold's books and some books and algorithms. Sure there are a bunch of undocumented things, but there their mainly because your not supposed to use them. You can't critisize MS's documentation guys. DirectDraw alone has 600 pages of documentation in a word file. As for not having source code so one can learn about the inner workings in solving a problem, all I can say, is that you shouldn't need to. First, programmers have been getting along fine for decades without the source to the OS. Second, if you need the source to understand whats going on, then the API is badly designed, and the documentation is inadequate. Third, its people who look at the source to take advantage of the system who are the root of all the legacy crap today's OSs have to carry. As for CS degrees in algorithms,
A) Windows is friendlier and more familier to work with
B) VisualC++ is $99 for educational purposes. My high school has hundreds of licenses for it. Whats so expensive about it?