The Hitchhiker's Guide to OpenSolaris

OpenSolaris: Sun Microsystems is open sourcing its Solaris operating system. The initial delivery is based on an intermediate version of the Nevada release of the Solaris system. It contains the OS/Net (aka ON) consolidation. Don't Panic! Additional pieces of Solaris will be open sourced in the future. The OpenSolaris team welcomes your feedback on what parts of Solaris should be open sourced next.

The Hitchhiker's Guide to OpenSolaris, despite being banged out in a couple hours and not being nearly as funny as Douglas Adams's Hitchhiker's Guide to the Galaxy, scores over the older and more pedestrian OpenSolaris Developer's Reference in two important respects. First, it is much smaller. Second, it contains the words ``Don't Panic'' in large letters, scattered through a variety of entries [1].

Consolidation: The Solaris operating system (also known as the WOS, or Wad Of Stuff [2]) consists of several consolidations, such as OS/Net (ON), X, GNOME, Admin, Install, SFW, and Devpro. Each consolidation is built as a unit and typically delivers multiple packages.

There are a number of implications of this structure. One is that different consolidations have different policies for how they build and test their code. In fact, the different consolidations don't even have uniform policy for where they put their source.

You also need to understand that some stuff that you might expect to be in ON is, in fact, in a different consolidation.

The upshot is that most Solaris kernel engineers have no idea where to find the source for the package tools or libm.

ON: This is the only consolidation in OpenSolaris at this time. The open code in ON consists of 27,916 files and 9,185,408 lines of text (as of Opening Day). The code is broken down into the kernel (uts[3]), basic libraries (lib), basic command-line utilities (cmd), some developer tools that aren't part of any Solaris product (tools), and boot code (grub, psm, and stand). User-level header files mostly live in head, though they may also be found in lib. Kernel header files live in uts and are used by both kernel and user-space code. Package definitions are in pkgdefs. Common code that is shared between the different trees is in common. See the Developers Reference for more details.

The ucbcmd, ucbhead, and ucblib directories contain compatibility libraries and utilities for SunOS 4.x. Despite the name, these trees are not general-purpose BSD compatibility source, though there are rumors of developers who would like to change that.

Some fairly large chunks of ON are missing in the OpenSolaris tree. Don't Panic! A lot of what's missing is cryptography source or things that won't build unless the crypto source is in the source tree. The OpenSolaris team was hoping to have the crypto code available at launch. But for various logistical and legal reasons, they were not able to make it happen. With a couple small exceptions, this entire wad of code should be available in the next delivery.

Another chunk of code is missing for legal reasons. The writer of this guide is not a lawyer, does not deal with lawyers, and wishes he didn't have to deal with all the secrecy that the legal issues seem to require.

A third chunk of code is missing because it will not build, because it depends on something in one of the first two chunks. Sun's ON development team is somewhat fanatical about clean code, and that includes not having random bits of stuff floating around in workspaces. The OpenSolaris team is considering making this third chunk available separately. Though after the crypto code is available, this third chunk should get a lot less interesting.

There is one final chunk of code that is missing, sort of. This is code that belongs to consolidations other than ON. Some commonly requested items from this chunk include libm, the packaging tools (pkgadd, etc.), the Solaris installer, and various open source utilities that are delivered via the SFW consolidation. has a list of the things that fall into the first three categories.

I own the workspace that OpenSolaris is currently built from. I've been at Sun for almost 13 years. For most of that time I worked on NFS, which is just a small piece of ON. One of the reasons I signed up for OpenSolaris was to learn more about the rest of ON. It's been educational and fun.

Source Code Management: The initial source code delivery system for OpenSolaris is biweekly tarballs. Don't Panic! Sun realizes that this isn't tenable for serious development work. The original plan was to (initially) provide a one-way bridge from Teamware (Sun's SCM tool) to CVS. But CVS doesn't handle renames, which are rather common in ON. So the current plan is to provide a one-way bridge from Teamware to Subversion. As described in the Development Process Plan, external developers will submit diffs to Sun engineers, who will apply the changes to the internal workspace, which will then be reflected externally via the bridge.

Unfortunately, the Teamware/Subversion bridge is currently not owned by anyone. If you're interested in working on this, please speak up on the Tools discussion list.

The long-term goal is for the master workspace to be external, and for external developers as well as Sun engineers to have commit privileges.

Nevada: Nevada is the code name for the Solaris release that will follow Solaris 10 (S10). Why the name Nevada was chosen, instead of, say, Fred or--to pick something totally absurd--S11, is a story that will have to wait for a future edition of this guide.

I was hoping to get this written for Opening Day, but like the rest of the OpenSolaris team, I was pretty busy with the launch itself. I'm hoping to add more entries as time permits.

[1] This will have to do, at least until the W3C adds <friendly> to HTML.

[2] I'm not making this up.

[3] UNIX Timesharing System

Technorati Tag: OpenSolaris

Technorati Tag: Solaris


Post a Comment:
Comments are closed for this entry.

Random information that I hope will be interesting to Oracle's technical community. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.


« June 2016