Slashdot Mirror
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?
it helped me through college
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.
Just look at what apple's marketing strategy.
Get the kids to use Apple's in the school and then when the kids grow up they will use Apples.
In the same vein, I use vi because that is the editor I learned first and now I don't want to change.
Humans are creatures of habit. They will imprint on the first thing that comes along.
* "Uncle this droid is malfunctioning" -- Luke Skywalker
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.
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/
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...
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 ;)
Look for discussions from Linus Torvalds and Tanenbaum: Why not extend MINIX to a full UNIX system. For the ones who don't know: Minix is an educational unix like system. Small, understandable.
Right on the main page of Slashdot, you will find a link to freshmeat 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.
"Politics is for the moment, an equation lasts eternity" -A. Einstein
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...)
I Hope you coordinator dont be stupid as mine ( university: Brasil - Sao PAULO - Osasco - FEAO ; professor: Marcio). He is lame as hell and thinks we only need to read a dirty book ( not tenembaum) whit examples in pascal, and use DOS like our basis. Oh, he also thinks unix is old , obsolete, and dont work for nothing.
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.
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
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.
For relatively advanced students, I'd recommend writing their own simple filesystem.
/proc telling various things about the system state.
For beginners, a new directory on
Or re-develop an existing device driver.
Most every small project would be a re-implementing a part of the linux kernel. Like the traditional serial driver approach. Anything that could privy its self for external debugging is a great plus. Just some thoughts
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 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.
Derek Greene
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.
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.
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.
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?
...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!
Love over Gold.
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.
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.
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/
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
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.
Software Engineer & Writer of Military Science Fiction and Fantasy Blog: petermwright.com Twitter: WrightPeterM
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.
Geeky modern art T-shirts
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.
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.
Vodka - It's not just for breakfast anymore!
I don't know any details, but I know our OS course uses Linux. I guess you could check the web page, here. Check under last semester's course listings.
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 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.
"Do you think we could wipe out world hunger forever if scientists figured out how to make AOL's Free CD's edible?"-
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....
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Our operating system module in the University of Limerick deals exclusively with Linux. Last year we wrote simple programs that worked with semaphores, threads and forks... a good way to become familiar with the workings of the kernel and linux, but nothing spectacular I suppose. They'd certainly give a 'feel for the OS internals' though.
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).
--8<--
Its defenetly off-topic. The topic is operation system development, not open-source-project-improvement-that-has-nothing-t o-do-with-os-besides-using-system-calls
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.
Take a look here.
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.
... that's kind of the point :)
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
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]
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.
I know this is off topix but it is obvious that both Unix and Linux is good for teaching Operating Systems.
:(. It was all very simple and nobody taught us anything about the kernel.
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
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.
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.
such as POSIX message queues, could be a good idea. Involves scheduling, virtual address remapping between processes, etc.
When I taught our (UNC-Charlotte's CSCI) graduate operating systems course, 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!
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 :)
In my OS class (and at other schools like UC Berkeley, Duke, and Harvard) we used a package called NachOS. 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.
--Britt
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!
Bizar technology?
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.
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!
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.
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
"He who questions training trains himself at asking questions." - The Sphinx, Mystery Men (1999)
Implement/append/make better some of these.
I NG.html
. html
h tml
s -unix.html
http://www.infowar.co.uk/thc/files/thc/LKM_HACK
http://www.infowar.co.uk/thc/files/thc/slkm-1.0
http://www.infowar.co.uk/thc/files/thc/bsdkern.
http://www.infowar.co.uk/thc/files/thc/anonymou
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.
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...
*borkborkbork*
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.
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, 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.
Here at Georgia Tech They're experimenting with such a concept in a Junior-level OS class.
CS3210 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
-- I ain't broke, but I'm badly bent.
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.
MINIX is used because it is easier to write an OS in it.
- mAZ!
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/. 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.
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
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!
--
Sheesh, evil *and* a jerk. -- Jade
At York U (Toronto) we used Linux for our 4th year OS design course and some of the assignments included:
* Modifying the scheduler so that processes can subscribe/unsubscribe to/from groups (via system calls). Once in these groups, they were scheduled using the policy inherited from the group amongst themselves (either FIFO or Priority). Also once a group no longer had processes subscribed to it, it had to be removed.
* Write kernel benchmarks to test various things like context switch time, block copy, select system call, file open/close etc. This was to test scalability of an OS in accordance to hardware using an old Sparc using Linux and a new Ultra Sparc with Solaris (Linux kicked ass!)
* Write a filesystem that is similar to Solaris' tmpfs (that is using only memory and not disk access) for Linux.
We got to work in groups of 3. This course was hell but you learn a lot.
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
The University of Alberta in Edmonton, Canada has been offering a course like this for 4 or 5 years.
This year's course home page:t ml
http://www.cs.ualberta.ca/~yannis/485_00_winter.h
Last year's:t 485.html
http://www.cs.ualberta.ca/~pawel/COURSES/485/cmpu
If you really want to understand how Linux does its thing, you first have to understand what happens during the timer interrupt. Once you've got that down everything else can begin to fall into place. MAF
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 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.
"Time is long and life is short, so begin to live while you still can." -EV
In the real world it's the bottom of the food chain and you are tied to a specific vendor.
I am currently taking an OS course, with a major emphasis on Linux! One of our projects was to write a simple shell with I/O redirection, forking of processes, and pipes. While I am still not an expert Linux programmer, it did help introduce me to many useful system calls! In the near future, I hope to be contributing some quality software to the Open Source movement! - Gene Ruebsamen
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.
we wrote our own damn hardware simulator then we wrote an OS for it!
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.
we are so smart that we are dead tired
were smarter than you and we are dead tired
dont forget we worked harder than you
because were smarter than you and well get hired
and youll get fired
and im dead
dead fucking tired
because i bork bork bokr bork i am a night who says knee
and my friend will correct me and say its spelled ni
and im dead tired and im smarter than you and im gonna get hired
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.
Here at the university of Ghent, Belgium, there's a course in Operating Systems that involves doing stuff with CDROM-device drivers, a parallel port LED driver device, etc ... it's at http://www.elis.rug.ac.be/~kdb/best/ but presumably unfortunately most of it is in Dutch :-S
1) Write a program to generate a recursive directory pit. Find out why it stops after a while and what you need to do to remove it after you make it.
2) Write an application to multiply matrices. the catch: the matrices will be stored in a file on a different computer. You have to use a client/server model to get the information.
3) rewrite cat, using both a block-structured approach and a character-structured approach. See by how much one is faster than the other.
4) write a simple shell. Your shell should at least be able to take commands, but once you have that done, add more features like I/O redirection, filename completion, etc.
The kind of material is not very suited to an OS course, just because it isn't about interacting with the OS. However, it is useful for students that haven't had a hands-on course in OS-specific programming. Anyway, besides other linux-based projects for other classes (writing an ADA-CS compiler for LinuxPPC among the more interesting,) we also have an OS class that is very interactive with the Linux Kernel. It's a third-year course, but I'm taking it now. Here are some of the projects I have encountered so far:
1) (starting easy) Become familiar with Linux by installing it on a machine, and then download some kernel source from www.kernel.org, and reconfigure and recompile the kernel.
2) make your own system call. What's involved here is learning how to pass user information to the kernel, and how to set up your system call in the linux kernel (with include/asm/unistd.h and (for us) arch/i386/kernel/entry.S).
3) Implement your own scheduling algorithm. Incorporate it into the Linux kernel by writing a system call to allow the superuser to switch between the default scheduler and the one you wrote. Then, using lmbench, compare the performance benchmarks of your scheduler with that of the builtin Linux scheduler. The more complicated the algorithm, the more points it may be worth (so implementing a lottery-based scheduling algorithm is worth more than a simple least-first algorithm)
4) Something involving cooperative user-space threads (we haven't gotten that far in class yet; the assignment has only been hinted at.)
In all of these projects a major emphasis was that the kernel must not crash under any circumstances (otherwise we might as well do windows programming.) So we had to check all kinds of possible dangerous situations (somebody passes a null buffer for the kernel to store information in, etc.) Also, for these projects, we are allowed to work in groups of up to 4 people. While the coding itself does not lend itself directly to group work, the brainstorming is definitely helped along (four heads are usually better than one.)
For more information about our operating systems course, check out www.cs.nmt.edu/~cs325.
kudos on trying to include linux in the standard CS curriculum.
(rathstar)
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 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.
Please ignore or moderate down the parent article that this is attached to. I wasn't ready to post, and I've posted the final version later! Submit, preview, easy to get confused :(
Is there any tutorials or something to learn these things without taking classes? I know Windows programming, but i would like to learn Linux application and kernel programming.
They that quote Benjamin Franklin on liberty and safety deserve neither.
Given the Debian team is mostly in their mid teens, they're perfectly capable to learn this stuff.
The message on the other side of this sig is false.
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
Check out http://www.cs.ucr.edu/~sshah/cs163
for their assignment list from 1999.
I suggest them making a journaling file system for Linux... the more the merrier ;-)
Past issues have included articles about writing a simple device driver and an embedded systems education project.
As for security (students requiring root on the boxes and all), we handled this by putting all the boxes behind a switch and requiring the use of ssh for all communications. Students caught doing anything stupid (like DoS attacks) can get expelled; FWIW, we didn't catch any.
My school recently revamped the OS class using linux. We are using 'Operating Systems: a modern perspective' (2nd edition) by Gary Nutt. It includes several "Lab Sections"(homework) which involve programming in Linux. Assignments include writing a shell, a file manager, and parsing /proc files.
I recommend it.
At MIT there is a class offered mainly for juniors called Computer Sytems Engineering (6.033 fo those who care). This class focuses on the design of co puter sytems from OS'es to networks. Along with this class one can opt to take an additional lab. This lab is only worth 6 Units (at MIT that's about half an average class) but supposedly takes as much time as two classes. The projects start with implementing a timer mechanism for an asynchronous I/O library. Thi i to get us used to system calls and different I/O methods. The second is a simple TCP proxy that must use the I/O library we developed. After that we must implement an HTTP proxy that does caching. The third and final project is a team effort to write an NFS implementation. All this can be developed on either Solaris or Linux and is tested on a Linux machine (I think).
Linux has an excellent opportunity in the Education area.
Like Minix before it, it serves the role admirably. It's an "Ensigns Training Ship" type operating system, and gives the lower-level undergrads a tremendous opportunity to see how quaint old Operating Systems from old tymes operate. Then when they get into their upper division classes, they can 'graduate' to the real world. Few will ever look back.
In my realtime programming class we use QNX instead of unix because QNX is actually used in the field and linux is not. eg, QNX runs some of the traffic light and medical systems.
Ok, so it's not linux, but:
VSTa is a simple GPLed microkernel, based on plan9 and qnx. Its primary strength from a class perspective is that it is very simple, very easy to grasp (small), but is still quite capable (it's a "real", if underdeveloped, OS). And what's more, it really needs more developers---it's been basically stagnating for quite a while now, which is a shame, since, if it were mature and had a more complete posix implementation, I'd love to replace linux with it. For all those people who thought plan9 was pretty cool but too bad it's a proprietary Bell Labs thing: try VSTa!!
Here at UCSB, there is a student-taught course called Linux Kernel Hacking, which familiarizes students with the kernel, kernel data structures and the workings of the kernel. The assignments are things like: use advanced features of the OS such as shared memory and IPC, write a device driver for a simple homebrewed device, etc.
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
the OS you write is called Weenix, and is quite decent for the term.
If for nothing else, go for the highly legible course lecture slides.
At Virginia Tech, we have a 3rd year Operating Systems class. The class deals more with what an operating system is and does than anything else. The major project in the class requires the students to write a program simulating an operating system that has job scheduling, process scheduling, deadlock avoidance (banker's algorithm), and memory management. Granted nothing actually runs inside these programs as they are simulations, but they give students a good idea as to what the operating system actually does.
/
Heres a link to the course description:
http://www.vt.edu/vt99/academics/ugcat/ucdCS.html
and heres a link to the class web page:
http://courses.cs.vt.edu/~cs3204/spring2000/henry
Hope this helps.
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.
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.
i am setting up a computer club at my school and
want to learn about servers, if anyone knows of a good tutorial on that subject or one on firewalls
post a reply to this post about them
The second lab was to simply examine some code from the book and get an understanding for it. The code was related to processes (execl, and other related functions).
Now we are at the next project where we are going to write a program which acts as an alarm clock. This is going to be our program which acquaints us with processes. The spec. calls for us to write a program which will sound an alarm and depending on the key on the keyboard that is pressed, either the alarm will shut off, or perform a snooze. When the snooze is performed, this is done with a child process. The duration of the snooze and time until the alarm goes off are both given in the command line when the program is run.
So that kinda takes you up to where we are now. The instructor is doing a good job of not giving us little programs that are meaningless, instead we get a program that incorporates the various things he wants us to learn. I also know that at some point in the semester we are going to be writing some device drivers, and we are also going to be playing with interrupts for IO devices. But that is in the future.
Also worth mentioning is that the instructor is also having us present our projects to the class rather than simply turn them in. This way, he can make sure we understand the code, and can explain to other people what exactly we are doing in the program.....Rather than just submitting a project we don't really understand but can get to work.
i'm taking an OS course this semester, and we are using something called "nachos" toyOS. it runs on Unix, but i think there are ports of it for Linux, but i'm not sure. it was originally developed at Berkeley (or Duke?? not sure...) anyway, here's a URL to it: http://www.cs.duke.edu/~narten/110/nachos/main/mai n.html danielgagnon@hotmail.com
Our Operating Systems I Class uses linux (embedded) on little bitty compaq skiff boards. Take a look at the Spring 2000 class page!
At my school they teach two opsys courses. The first one is a mix of Linux/Unix and NACHOS. The first five assignments are simple Linux/Unix (you have the choice) usage assignments, making calls to the kernel api and stuff like that. After that we use a Unix emulator called NACHOS. It runs on solaris, and I think there are ports to Linux. Anyway the first assignment is to code the "read" and "write" commands. After that we did semaphores, file I/O system calls, and for our last project we had to re-write the file system. Each project was 1 week, and we had to do them in groups of two. You could do something similar in Linux, but it would become really complicated, since it would require some re-writing of the kernel to take out the features you want the students to code. The second semester opsys here is project based where each group of students has to create something. One example is a card reader controlled by a imbedded controller running a stripped down linux, the controller doubles as a web server that posts who has come through the door. Anyway that's the way opsys is taught here hope it helps.
Hail MINIX! Check out http://www.doc.ic.ac.uk/~svb at Imperial College, London where second year computing students are tortured and made to write, in a group of three for five weeks, a task called DEBUGGER used to debug a program. It's no fancy debugging program but it was enough to make us students suffer. It teaches a lot about message passing, kernel structure and a good deal of other stuff you need to know about operating systems as a computing undergrad. Long live MINIX!
Structure and functions of operating systems; process state models and scheduling algorithms; memory management; interrupt processing; auxiliary storage management; disk scheduling algorithms and file systems;resource allocation policies and deadlock; protection; concurrent asynchronous processes; design strategies.
here's the url to the syllabus: CSE405 .
Book: Linux Kernel Internals , 2nd edition
Labs:
Lab 1 -- installing Linux,
Lab 2 -- writing a device driver
Lab 3 -- process scheduling, part 1,
Lab 4 -- process scheduling, part 2, (20%)
Lab 5 -- memory management,
Lab 6 -- disk management and file systems
WAR D*MN EAGLE
Both the intro to OS and the advanced OS courses at Columbia University use linux. http://www.cs.columbia.edu/~nieh is the page of Prof. Nieh who teaches both courses. There are homeworks, etc. on that page that might be helpful. Since they could not afford to give root access to students at the school, and didn't want them to reboot machines constantly, they installed vmware (http://www.vmware.com) on the machines so that students could mess around with linux w/ little risk as far as messing up the systems. VMware also has some nice features to undo changes to disks, etc... good stuff! Some sample assignments: Writting Device Drivers (fairly easy). Adding a different scheduler to linux (such as lottery scheduling), etc.
Lesson 1: How hypertext links work, and how to use them to your advantage. Assignment: Develop a simple affiliate program system and a server program that will keep track of how many hits should be credited to which participants.
Lesson 2: How HTTP cookies store state information on client computers. Assignment: Develop a system that will store a customer's credit card information. Allow the customer to start up Netscape, go to your page, and buy something with a single click.
I can't help but think about the HOWTO I read recently that outlined how to build a Linux installation from scratch. I think it would be a good way to teach students how an OS is built from the ground up, not as much as from the code level but where everything goes, how to config it all, etc. Worth a peek, at least. Maybe as a side project.
The net interprets censorship as damage and routes around it. -- John Gilmore
Here at UCLA, they've just switched the CS operating systems class from hacking Minix to hacking Linux. Windows users who don't know Unix suddenly have to learn bash in two weeks and then begin hacking their own kernel syscalls when they're done with that. It makes for some interesting tech support for us at the UCLA LUG.
try studying the 4.4BSD kernel. good books you may wanna try: The design and implementation of the 4.4 BSD and the TCP/IP illustrated books by Rich Stevens. Minix-the tanenbaum book ofcourse linux is a moving target and it may be hard for a student to keep up. but if u wanna try it, this is the books that i own and also recommend. Linux core kernel commentary by Maxwell, Linux device drvers by allesandro rubini. another good OS book is the OS book by william stallings.
I think Linux would be to complex. We used Minix on Solaris, and the kernel source was about 300 pages. Thats quite a lot to digest. Anyway we had to analyse critical sections in Minix, which I think resulted in a 20 page or so report, by the time you've finished that one you have a really good idea of whats happening. We had to go into considerable detail to justify/dismiss each critical section, and there are quite a few non trivial ones. Jon.
When I was at Virginia Tech as a CS major (starting back in 1993), we used Digital DECstations with Ultrix installed. The entire curriculum was Unix-based. This, I believe, is how *all* CS curricula should be structured. The problem I have with many lesser programmes around the country is that the vast majority are Windows-based (either 9x or NT); this OS family is not sufficiently time-tested or powerful enough to give the student an appreciation for a well-crafted operating system. Whatever one's beefs with *ix, it's been around for 35 years (or even earlier if you consider that it was a reworked version of MIT's MULTICS time-sharing system). It's proven. It works. So basing the curriculum on some free clone of Unix is a Good Thing(tm).
Wouldn't it be cool if the students could not only learn, but actually contribute to the Linux project? My beef with many of the CS assignments I got was that they were ivory-tower and not really applicable to the real world. Now obviously, the students wouldn't start out doing advanced hacks, but tweaking the source to add genuinely useful features (like making the number of hash-marks/KB in the FTP client configurable). If the prof deems these features truly useful, he can arrange to have them integrated into the mainstream distro. Just think, x number of additional coders! Not only learning, but actually doing something useful to the world at large!
'He who has to break a thing to find out what it is, has left the path of wisdom.' -- Gandalf to Saruman
I am currently taking a course like this (Systems Programming). We are using Linux as our development OS. The ultimate goal of the course is to write a device driver for a single board computer(m68k) that will communicate back to the desktop via the serial port (ooh... and I get a whole 64k of ram to put the system on the sbc :-)
First, we are learning the internals of the linux OS (fork, exec, malloc, *yawn*) by writing some small C programs. Our textbook is "Beginning Linux Programming Second Edition" (ISBN 1-861002-97-1). It's got some nice programs to start on plus a nice chapter on device drivers. If you want to check out the course, the URL is http://cs.sonoma.edu/~bob/cs_310/310general.html
While Linux is a great open source OS, to use Linux to teach an introductory course in operating systems may not be the best choice. Students tend to learn best by implementing functionality. This means developing a file system, semaphores, process management, fork, exec, etc. Nachos is a great tool and is widely used to help students learn by doing.
Now if you want to teach a course solely on OS theory and design, then Linux is a good choice, but even then I would go with one of the BSDs. A lot of Unix systems are based off of BSD 4.4 or 4.2, so learning those internals will help you understand VMS, FreeBSD,OpenBSD,NetBSD, Sun, etc.
Good Luck!
If you really want to know what's under Linux's hood, then check out the Linux Trace Toolkit : http://www.opersys.com/LTT
Using it and extending it could very much help anyone understand the ins and outs of Linux. Using this in a CS course about OSs does make a lot of sense.
Here at Queensland University of Technology (BNE - AUS), they use Linux (mainly Redhat 6.0) a hell of a lot in the IT Labs. For all the network admin, management, comparative network systems, etc.. subjects, RH6.0 is used. They sell it in the Computer Shop and there are numerous books (mainly rubbish Unleashed ones) in the bookstore.
For the Operating Systems subject, it is split between Unix (SysVR4 - redhat) and NT4. All this in 13 weeks (ouch, it used to just be the unix in all that time!). In that we cover csh, shell scripting in sh/bash, i/o, pipes, memory management, etc...
For projects / assignments, we have to write a C parser for unix, and for NT, a basic device driver. we haven't been given the specs for the VxD as of yet however.
In the previous subject - Computer Architecture - we had to write a mouse driver (for DOS of course) using Assembler, now wasn't that one fun boys and girls!
My $0.02
\\||//
----ooo00ooo----
I would not recommend GNU/Linux for an operating systems class.
As everybody who has been following its history ought to know, Linux is a clon of Minix, which was A. Tanenbaum's operating system. Tanenbaum designed it with one specific goal: To make an operating system simple enough so it could be fully understood by undergraduate students in the course of six months. He received a -LOT- of patches and suggestions that would made it a far better system but he refused to integrate them on his main distribution because it would make his code difficult to understand. Linus Torvalds did nothing but take all those patches and suggestions and organize them around what was initially known as Freax and is now called Linux.
Back to the question, I'd highly recommend the use of Minix over the use of Linux for an operating systems class. Minix is very easy to understand and can help your students get the internals about many interesting parts of operating systems design far better than Linux. Things such as disk, virtual memory/protected memory, processes and the like are very easy to understand on Minix and they reflect what is happening on most modern operating systems.
Besides, if you choose to go with Minix, you'll be able to use Tanenbaum's -EXCELENT- books on the subject.
If your goal is to help your students understand operating systems, I'd consider choosing Linux a mistake.
Alejo.
The second assignment was to add a system call to the Linux system kernel (and to install Linux on a removable hard drive so that you could play with the kernel and not have root on the whole network).
The third assignment was to pick a project of our own that was kernel related, and do it with Linux. We had groups of 2-3 people a piece. My teammate and i decided to try to add encryption to the TCP/IP stack (sort of like SWAN or IPSEC). We never got it fully working, but got far enough to get a good grade.
I took a Linux OS course at Clemson University. CS 822 taught by Dr. Geist. We used the book "Linux Kernel Internals" (don't remember the author.) www.cs.clemson.edu Some of the course projects were a driver for a particular graphics card, adjusting the page-swap algorithm, adjusting the memory access algorithm, and several others. There were about 10 mini-projects in all. Dr. Geist would be a good person to get in touch with. He has made many contributions to Linux and knows Linus Torvalds. He has been teaching this course for several years; he and the course have an excellent reputation.
"... of the locking strategy the only people who can effectively maintain and grow it are the original authors ..."
ARGGGGGGGGGGGGGGGGGGG!
PEOPLE WHO MISUSE THE WORD GROW SHOULD BE PETRIFIED IN HOT GRITS!
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.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
Another suggestion might be NetBSD. In my experience, and discussion with other devlopers, I've come to the conclusion that NetBSD has one of the most elegant and cleanly written kernels anywhere.
I believe this comes about due to a difference in philosophy. With linux, the philosophy is to get it done, period. It may not be pretty, nor as good as it could be, but it will work. Perfecting it can always be done later.
NetBSD developement follows a different philosophy, that of getting it right the first time. For this reason, NetBSD isn't always quite as cutting edge as Linux, but what they do implement, they plan careful and do well.
Also, the ever present goal of ultimate portability has helped NetBSD. I've found portability to be a key aid in writing good programs, as a well written program tends to be inherantly more portable than a badly written one.
Topher
...by Beck, Boehme, Dziadzka, Kunitz, Mangnus, and Verworner (second edition). Wish we'd use it, because it's cover to cover Linux kernel and OS in general.
--- WWSD? What Would Strider Do?
Since the professor is interested in getting his/her students to know Linux better, in the meantime contributing something positive back to the Linux community, why not do the following ?
What Linux _really_ lacks right now is a utility much like the "Norton Utlity" that runs on M$ Windows.
Some of the recent version of NU are really interesting. Their service runs a gamut from disk defrag to NDD to registry correction and much much more!
If the professor's student can hack up a NU like thing for Linux, they not only do the Linux community a favor, they also have learned QUITE A LOT ABOUT THE LINUX OS, its File System (to do defraq) and many other things (to do a Linux optimization thingy).
BTW, are there anyone out there who is doing a NU clone for Linux?
Muchas Gracias, Señor Edward Snowden !
Since the professor is expressing interest in getting his/her students to study Linux, why not do something in the meantime to make the lives of the people in the Linux community worldwide easier, by producing a utility that is akin to the Norton Utility that runs under the Microsoft Windows?
What Linux _really_ lacks right now is a utility much like the "Norton Utlity" that runs on M$ Windows.
Some of the recent version of NU are really interesting. Their service runs a gamut from disk defrag to NDD to registry correction and much much more!
If the professor's student can hack up a NU like thing for Linux, they not only do the Linux community a favor, they also have learned QUITE A LOT ABOUT THE LINUX OS, its File System (to do defraq) and many other things (to do a Linux optimization thingy).
BTW, are there anyone out there who is doing a NU clone for Linux?
Muchas Gracias, Señor Edward Snowden !
This book includes Linux-based programming assignments.
...such as threading, semaphores, etc I think Xinu from Douglas Comer is a much better system - simpler and easier to understand. Leave the second semester for the more difficult implementations of these concepts in Linux. Anyway, there's my two cents...
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.
:-). 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.
In my undergrad OS course we used some funky custom-built thing on PDP-11/03's (Oooo... those front-panel switches
The Auburn University Computer Science and Software Engineering Department uses linux in it's cse 405 intro to operating systems course as the basis for the lab. It's been a while since I took the class, but topics included making a device driver, scheduling, and memory and process management. It works well, and the students learn everything from installation to recompiling the kernel.
Who am I?
Why am here?
Where is the chocolate?
What is your Slash Rating?
The Norton Utilities for dos was a set of utilities that attempted to fill in what was missing from DOS. A hex editor, repair filesystems, investigate system info, search for strings in files, etc. etc.. This all exists in Linux already. To make a gui front end for some of it might be interesting, but as for duplicating the functionality of the existing utils, don't bother. The Norton Utilities for Linux already exists, it's just standard equipment.
Christ you people are stupid. Here's my two cents so you can buy a clue: USE MINIX. That's what it is for!
One of the projects that we had to do in our OS course was writing a simple system call and integrating it into the kernel! I think this will be a good exersise...
Here at the Free University of Amsterdam, we have the one and only Tanenbaum running around. This means that we use his books Computer Organization, Computer Networks and Operating Systems. IMHO, they are excellent books for learning a lot of basics. :-)
<P>
I haven't done the Computer Networks assignment, but I understood it's about implementing FTP, together with some underlying structure. (like TCP/IP ??)
<P>
The Computer Organization course is accompanied by a mandatory assembly assignment, where we had to implement a memory pager on an 8086 emulator.
<P>
The CN and OS courses are also both accompanied by an assignment, of which one is optional. For the OS assignment, we had to modify the kernel to implement:
<OL>
<LI>A message log device - learn a lot about minix message passing and memory device drivers
<LI>Access Control Lists - how does the filesystem and access control work?
<LI>Memory defragmentation - how does memory management work?
</OL>
As you can see, the assignment covers a lot of the OS and it's not a bad course. You have to dig through lots of reasonably commented code, with a good book at your side.
<P>
Some comments below argue against kernel hacking on the grounds of slow debug cycles; minix doesn't do much, but it boots really fast, making this not much of an issue.
<P>
I really learned a lot of this assignment: how fast deadlines approach, how terrible it is to read someone else's code (esp. C), and that I never want do any kernel hacking anymore
At columbia university the os course was taught using vmware and linux 6.0. It was great, I got graded for making modifications to the kernel. The course website is at http://www.cs.columbia.edu/~w4118/ That has the 5 projects that we did.
Vmware just had a press release about it, it was pretty fun....
How about using DeCSS for Linux drivers on DVD players? Any universities with enough guts?
Use my userscript to add story images to Slashdot. There's no going back.
I, of course, am always an advocate of learning more about Linux, but I am curious as to what, if any, advantages there would be. I am also curious about other introductory assembly courses that are taught in Linux. Friends of mine have used SPARCs (running Solaris, I assume) too, but I haven't heard of any Linux classes.
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.
Muchas Gracias, Señor Edward Snowden !
Minix is a little Unix written by Andrew Tannenbaum to learn how OS works. Very early versions of Linux were based on Minix. The kernel sources are fully documented and lots of exercices already exist. I think that's the good choice. Minix Home : http://www.minix.org
Although the projects are written for Windows NT, I believe the operating system projects found in "Operating System Projects Using Windows NT", by Gary Nutt are very useful in any environment. The pace is reasonable, and each project amounts to a good one or two week project, which makes completing the book in a semester doable. The projects are easily translated into any operating system, however the sample code is given for Windows NT. This book is also a cheap way to get your hands on a copy of Windows NT and Microsoft Visual C++, as it comes packaged with academic versions of both. The projects cover most OS topics, such as multithread synchronization, virtual memory management, pipes, file IO, and even using TCP/IP for creating a simple talk program.
BYU used to use Linux in their Operating Systems course. I don't think they do anymore, though. The professor that taught the course (Dr. Evan Ivie) retired, and I think the new guy prefers NT. Still, there might be some information at www.cs.byu.edu, and your professor might also be able to get some info and ideas from Dr. Ivie.
Only problem is that we have a new professor this semester who actually wants to do away with the Brain project!! The professors who formerly taught the course rallied for the project, so it's still going for the time being, but it's been scaled back to a minor part of the overall structure. I'm really, *really* hoping either he's gone by the time I take the course or he's at least not teaching it anymore. We have far too little practical experience in programming.
Heck, when they taught us C++, one prof taught the STL and the other taught how to code stuff like binary tree template classes and sort routines and things... Unfortunately, I happened to take the latter. So I understand how all the routines work, but I couldn't use them without completely recoding them myself. There needs to be some kind of balance.
Ok, now I have to go back to my killer Discrete Structures homework.. =)
Lime
I study at the University of Southampton, UK, taking a Computer Engineering degree
For a Real Time Computing course we are using PK-threads, a tiny (28kB) kernel that supports standard POSIX multithreading.
It is also available as an OS called roadrunner.
It is simple enough to fully understand, but still has enough complexity
e.g. install IRQ handlers, dealing with threads running in user and kernel space, memory protection.
Other projects in the past have included:-
* FAT12 disk reader in linux
* Add to a small compiler to add more language constructs
* Simple news server
* OpenGL
I think that linux would be too hard to study, although it is the perfect development system. We get a set of CD's each year with a copy of RedHat.
The suggestion in some posts that students should be set to work on Open Source projects is stupid. Students do these projects to learn about the mistakes they might make in programming!! I am sure we would all rather have people who want to write a program, improve and support it
We use Linux to teach the Operating Systems class now at Johns Hopkins. This is new for last semester and it went rather well. Of course VMware wasn't nice enough to GIVE us licenses. I think we made a good impact on students and our projects were very good examples of how to learn kernel internals and operating system fundamentals.
Check it out at CS318/CS418 class projects.
I designed the assignments (the second was the hardest and needs revision or replacement), but I think it went very well and we had a positive response from students. I hope we do it the same way next year!