Poking around the OpenSolaris codebase (for sysadmins)
If you do much work with Solaris things like DTrace and
mdb -k, you
are sooner or later going to want to poke around the OpenSolaris code,
both for kernels and for utilities and so on. If you do this very much,
you are going to want your own local copy of the OpenSolaris codebase
(while you can use the OpenSolaris website, sooner or later navigating
through it will drive you mad). You can get a copy with Mercurial; see
here for instructions on
how. For spelunking purposes, there is little to no reason to get the
binary only bits.
(Just to confuse you, OpenSolaris is called 'ON/Nevada' in much of this.)
Now, there's an important caution to this: OpenSolaris source is not
the same thing as Solaris source. You can generally use OpenSolaris
source as a guide to what you'll find with DTrace et al, but it's not
a sure thing (even if you go back in version history), and sometimes
you will find important differences. Some of these can be spotted by
looking at structure definitions in your own system's include files in
/usr/include, but not all of the interesting header files make it
there. In some cases you may have to resort to dumping structures with
Everything useful in the onnv-gate repository lives in
and I'm going to quote paths relative to this from now on.
- In general, everything has most of its code in a <whatever>/common
subdirectory (for 'code common across all architectures', I assume).
mdbsource is in
cmd/mdb, and the
mdbmodules are mostly in the
mdbmodule source can be the best way to find out interesting
mdbcommands and exactly what they do; this can lead to useful discoveries.
- most interesting kernel source is in
uts/commonin a relatively obvious layout. Many internal header files are in the
sys/subdirectory here; others can be found in the source area for their code, eg
fs/zfs/sysfor internal ZFS headers.
- ZFS commands rely on some ZFS libraries to do most of the work;
lib/libzfs. These are what you need to look at if you want to figure out the division between user and kernel space, and also what limitations are artificially imposed by
zfsand what limitations are real.
In general the repository history in the onnv-gate repository is not
very useful. Sometimes you can use '
hg log -v' and so on to pick out
the specific code change that fixed a bug number that you're interested
in, and thus see how applicable to your particular circumstances it may
(The other thing I've used the repo history for is to trace the code for a particular ZFS kernel feature that I wanted to use back in time to establish that I would have to use a relatively recent OpenSolaris build in order to get it.)