== 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 http://opensolaris.org/os/project/onnv/]] 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 _mdb_'s _::print_ operation. Everything useful in the onnv-gate repository lives in _usr/src_, and I'm going to quote paths relative to this from now on. * In general, everything has most of its code in a /common subdirectory (for 'code common across all architectures', I assume). * _mdb_ source is in _cmd/mdb_, and the _mdb_ modules are mostly in the _common/modules_ subdirectory. Reading _mdb_ module source can be the best way to find out interesting _mdb_ commands and exactly what they do; this can lead to [[useful discoveries ListingFileLocks]]. * most interesting kernel source is in _uts/common_ in 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/sys_ for internal ZFS headers. * ZFS commands rely on some ZFS libraries to do most of the work; they're in _lib/libzpool_ and _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 _zpool_ and _zfs_ and 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 be. (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.)