OpenSolaris Student Guide
'Introduction to Operating Systems:
A Hands-On Approach Using the OpenSolaris Project'
-------------------------------------------------
In the US during the early Spring of 2006, we developed University curriculum for OpenSolaris that consisted of approximately one to two semesters of lab exercises in the form of a student guide with a companion instructor guide. This curriculum introduced OpenSolaris as a project, a set of communities in which to participate, and a development process to learn.
Student Guide Overview;
The basics of processes, debugging, multi-threaded programming, kernel module characteristics, and scheduling were also discussed at a high level in the guide, as a primer to operating system computing concepts. In the second version of the student guide, revised during the fall of 2006, template character device driver development labs were replaced with modules describing basic ZFS administration and Zones management.
The feedback indicated that driver development was likely beyond the scope of undergraduate University students and it was clear that environment setup and basic administration were a barrier to OpenSolaris adoption to be addressed with students. This updated student guide was translated into Russian, Brazilian Portuguese, Japanese, Simplified Chinese, and Spanish in December of 2006.
Additional University Materials;
Meanwhile, the Bejing OpenSolaris education representatives developed extended sets of lab exercises in English and Chinese to be presented at the University level. These labs were bundled in a different format that provided usable code and targeted exercises with extensive input and output examples, discussions, and low-level specifics about real-world operating system development practices.
Conversations with developers at FOSDEM made it clear to me that expansion, and possibly combination, of both of the efforts cited above should be the next phase for the OpenSolaris University education materials.
In addition, we should develop a curriculum architecture that spans a four-year computer science degree program, using OpenSolaris in all of the code samples, lab exercises, and examples. We have the basic content for such an expanded curriculum in structured markup, so the development of an architecture for the coursework will comprise the bulk of new work, while the mechanics of implementation of existing content into new, approachable content forms aught to be trivial.
So, what could be the architecture of this content? I propose a strawman here, just to get the ideas flowing and all in one place, new revisions to this proposal will be made in coming weeks.
QUARTER 1:
0. primers in either SPARC or x86 assembly?
00. Architecture: how writing code in userland causes bits to flip in registers
I. Introduction to UNIX
II. Introduction to Object Oriented Programming and C
III. Introduction to Multi-threaded Programming
IV. Introduction to Algorithms and Macros
V. Introduction to Free and Open Source Software Development
QUARTER 2:
I. Solaris Implementation of UNIX
A. Read Rich Teer article; Comparison of FreeBSD, RedHat
Linux, and OpenSolaris
B. Complete online training; Solaris 10, Ten Moves Ahead
C. Read article; Getting Started with OpenSolaris and
VMWare Workstation
D. Text: Solaris Internals
II. OpenSolaris Environment Setup
A. Register on OpenSolaris.org and request free Starter
Kit in your native language
B. Starter Kit:
1. Preparation: backup & partition disk
2. Installation: single, dual, or triple boot
3. Configuration:
3a. Config users, wireless, and DHCP
3b. Test cdrecord, music, video, wallpaper
3c. Test printers, hosts, nodes
C. Subscribe to Academic and Research Community:
1. Introduce yourself on edu-discuss mailing list
with your University & degree program
2. Download and print latest Student Guide in your
native language
3. Download latest lab exercises in English or
Chinese
4. Explore code and comments with OpenGrok
III. Advanced C
A. Coding Style and Style Checkers
B. Conducting Code Reviews
C. Basic unit testing and quality assurance
D. libc
IV. Advanced Multi-threaded Programming
A. Text: STREAMS Programming Guide
B. Operating Platforms and Networking
V. System Administration and Performance Tuning
A. Text: Solaris Administration and Performance Tools
QUARTER 3:
I. FSS, Scheduler development and implementation
II. Virtual Memory Management, large pages
III. DDI/DDK Driver Development and Debugging
IV. iSCSI, ZFS and Storage Software Development
V. Virtualization, Resource Management, and Zones Development
QUARTER 4:
I. Kernel modules, dtrace, kmdb, mdb
II. ipsec, ipv6, ipQos, tcp, ipfilter
III. encryption, md5, sha1
IV. boot, acpi, grub, miniroot
V. ldap, cacao, sendmail, nfs, samba, apache, cron
QUARTER 5:
I. Basic Application development on Solaris
QUARTER 6:
I. Systems Integration with Solaris (SAMP)
QUARTER 7:
I. Database development for Solaris
QUARTER 8:
I. Web, Message, Application, and Identity Servers for Solaris
While I'm no educator, I question the inclusion of C++ in this curriculum given that the vast bulk of Solaris ( and by extension OpenSolaris ) is written in C. The dichotomy in presenting C++ and then using OpenSolaris source as examples could derail alot of students. I would start with C and primers in either SPARC or x86 assembly since the bulk of Solaris uses all three of those languages. Solaris will still provide a fertile source of object oriented programming design and implementation which should allow students to understand that objects are a "state of mind" and not just a "language feature".
I also think you are missing an architecture component. Software does not execute itself, and I believe students would be well served by a better understanding of how to deal with "the bare metal". Solaris is an excellent example of an OS design that decouples the OS from the underlying architecture. Studying this decoupling should foster new ports of Solaris to different ( an unanticipated ) platforms, as well as a better grasp of how writing code in userland causes bits to flip in registers.
And lastly, you may consider restructuring your progression so that students start in userland and then move into the kernel. My reasoning is that mistakes in userland only crash the user's program. Mistakes in kernel-land can be much more catastrophic (crashing the machine at worst, introducing subtle errors which are difficult to debug at best). Reducing the impact of mistakes will minimize the frustration of novice programmers as well as allow students to share hardware in constrained environments. This reminds me a great deal of curriculae devised around Andrew Tanenbaum's MINIX in the late 80s/early 90s before Linux really took off. Is it possible to feel nostalgic for the AT&T 3B?
Posted by Erik O'Shaughnessy on February 27, 2007 at 08:32 AM PST #
Posted by Steven Cogorno on February 27, 2007 at 09:07 AM PST #