Slashdot Mirror
Custom Kernels Used In Comp. Sci Programs?
pdowner asks: "I've just finished and handed in my latest Operating Systems Inmternals assignment for my degree in Computer Studies. It involved writing/modifying a timer module for a Microkernel implemented in modula 2, which is written by one of my lectures and is available from here. I am interested in finding out what microkernels other universities use to teach their students the insides of Operating Systems."
I can flesh that out a little bit.
:).
The codebase is only really
- Standard Solaris functions for manipulating process contexts. Solaris is a great environment for all this, since everything is provided for you
- Special memory tricks. Rather than deal with the real SPARC pagetable structure, their support library uses a memory mapped file (mapped based on a simple 1-level page table provided by the kernel we write). This makes writing the paging code much easier.
- Signal handlers for things like SIGSEGV and all, as well as a timer that goes off. These are translated by the support library into kernel traps (which we write). So when a user program gets a SEGV for a memory access somewhere in the memmapped file, we change the page table some, the support library remaps things approrpriately, and we continue running. The timer is much slower than a real OS's timer, so a process's timeslice is slow enough a human can watch it go by (maybe 1/2 second or so).
So yeah. For all you people who thought you were doing everything, there really was a support library behind the curtain pulling the wool over your eyes. Norm and I cought the little man in there a couple of times doing funky things a couple of times (ever notice how you never have to worry about page table addresses when you switch from realmode to virtual memory? in theory you should have to be very careful to keep your page table from, say, falling across a physical page boundry when you allocate it with VM enabled. the support library ignores such details
Basically this ends up giving us a real kernel that's very very close to the Sun hardware. I actually asked Greg (professor this semester) why they didn't use Nachos. The answer had to do with the oversimplifications Nachos makes. Yalnix is a much more complete environment.
Actually, Greg says he's planning on redoing project 3 for next semester. He wants to take DR-DOS (or possible his own little minimalist DOS-like OS. This project would be on Intel intead of Sun hardware) and replace interrupt handlers one by one until you have UNIX. Since the DOS disk stuff would still be in place, he could then add demand paging to the project. He said this was the Clemson graduate OS project. For CMU undergrads, he'd write the asm utility functions, and also we'd have the advantage of VMWare or Plex86 (so when we crash ourselves all is not lost; this is a major advantage of Yalnix -- when you crash the OS, you get a core dump). The cool thing would be, when you were done, you could boot your OS for real on the hardware.
A note to people who aren't familiar with the CMU OS course: it's considered the hardest undergrad CS course (18 units, that's 6 credits). The last two projects are a month long each, easily 30-50 hours a week in the cluster. But when you're done and can say to recruiters, "Yeah I've taken OS and I got an A" they offer to hire you on the spot.
Ok, enough wasted time. I need to go back to my filesystem (project 4, due Friday at midnight. eep!)
"Today class, our good friend Mr. Gates has given us some of the Windows 98 SE kernel to use as an example. We're to modify this fine example of coding and add some new features to it."
(A horrifying silence ensues)
(After a long two minutes, one of the students, Craig, raises his hand.)
"Yes, Craig?"
(Craig clears his throat, and tries to speak as slowly and clearly as possible)
"Sir, um, did we do something wrong to deserve this?"
At CMU, our operating systems class writes a kernel called Yalnix. It's a user-mode Solaris implementation, and we're provided a codebase to work from -- we're basically responsible for implementing the kernel call API, the scheduler, and the memory manager. Details available here.