h1. Source code location and installed location
The source code for DC is in the slim source gate. To get a copy of the slim source gate
{code}
hg clone ssh://anon@opensolaris.org/hg/caiman/slim_source
{code}
h3. usr/src/cmd/distro_const
* code for the main DC program
* distro_const.py is installed as /usr/bin/distro_const
* Most of the code is installed as the python module in /usr/lib/python2.4/vendor-packages/osol_install/distro_const
h3. usr/src/cmd/distro_const/utils
* common finalizer scripts and configurations
* installed in /usr/share/distro_const
h3. usr/src/cmd/distro_const/slim_cd
* Slim CD specific finalizer scripts and configurations
* installed in /usr/share/distro_const/slim_cd
h3. usr/src/cmd/distro_const/auto_install
* Automated Installer specific finalizer scripts and configurations
* installed in /usr/share/distro_const/auto_install
h1. Dependency on other Install modules
The Distribution Constructor application uses other install modules
h3. The Target Instantiation Module (TI)
* DC uses the TI module to create UFS and ZFS file systems.
* TI module has a special module for DC, usr/src/lib/libti/dcm.c
* DC uses TI via the C to python interface provided in usr/src/lib/libti_pymod
* All the DC code that calls the TI module are in usr/src/cmd/distro_const/DC_ti.py
* [TI TOI presentation|http://www.opensolaris.org/os/project/caiman/files/toi_td_ti_tm_orch.pdf], pages 18-33, page 25 is about the DC module
h3. The Transfer Module (TM)
* TM module is in Python
* It has 2 modes of operation.
** TM_PERFORM_CPIO
** TM_PERFORM_IPS
* The DC application itself only uses the IPS mode for populating the package image area, and setting IPS related properties. The DC calls all the TM calls in usr/src/cmd/distro_const/DC_tm.py
* The usr/src/cmd/distro_const/utils/bootroot_initialize.py finalizer script uses the TM_PERFORM_CPIO mode to copy files into the boot_archive.
* [TM TOI presentation|http://www.opensolaris.org/os/project/caiman/files/toi_td_ti_tm_orch.pdf], pages 34-43
h3. The XML parser
* XML parser is used for processing the manifest
* Both the command line and the python interface provided by the XML parser module are used by the DC to retrieve values from the manifest.
* [XML parser TOI presentation|http://wikis.sun.com/display/OSOLInstall/XML+PreProcessor+and+Parser]
h3. The finalizer engine
* It's a Python module located in usr/src/lib/install_utils/finalizer.py
* It's calls scripts and programs that are queued up in the order that they are registered
* A pre-defined set of argument(s) can be passed into the finalizer module so all those arguments are passed to each scripts and programs when called.
* arguments to the scripts and programs can be specified at the same time programs are registered
* DC registers scripts specified in the manifest into the finalizer engine to mold the final output for different image types.
h1. Major components of DC
h3. Diagram of DC program flow
!DC_arch_diagram.jpg!
h3. checkpointing
* Provides the ability to start or pause at a certain step in the build process
* The process of populating the pkg image area with packages specified in the manifest is the first step. Each of the finalizer scripts specified in the manifest made up all the subsequent steps.
* Implemented using ZFS snapshot
** The <build_area>/build_data dataset is snapshot for each step
** <datasetname>@step_<step name>
** Rolls back if you resume at that step
* .step_<step_name> files
** One file for each saved step
** Located at the build area
** Copy of the manifest file
** When determining which steps are available to be resumed from, the list of .step_<step_name> files are checked
* finalizer_checkpoint.py and finalizer_rollback.py are used for doing checkpointing for finalizer scripts
* All code related to checkpoint handling are in DC_checkpoint.py
h3. Logging
* Log files for each DC run is timestamped and are located in <build_area>/logs
* The detail log contains all outputs and errors from all commands and programs executed by DC
* The simple log contains only errors and warnings from commands and programs executed by DC
* The console output when DC is executed is the same as the simple log
* Logging in DC uses python logging
* Logging is initialized in dc_utils.py
h3. Bootroot
* Bootroot is created with a series of finalizer scripts
* The staging area for the bootroot is at <work_area>/bld_data/bootroot
* For the Slim CD, the series of finalizer scripts are:
** */usr/share/distro_const/bootroot_initialize.py*
Populates the bootroot with staging area with content specified in the manifest
** */usr/share/distro_const/slim_cd/slimcd_bootroot_configure*
Slim CD specific configuration needed to the bootroot
** */usr/share/distro_const/bootroot_configure*
Special configuration for the bootroot, such as importing SMF services, creating symlinks
** */usr/share/distro_const/bootroot_archive.py*
Calculate size of the bootroot, create an UFS archive of the configured bootroot content, and compress it.
h3. Manifest defaults and validation
* Utilizes the XML parsing module
* DC-manifest.rng specifies format of the manifest
* DC-manifest.defval.xml specifies the default values for different manifest fields
* DefaultsModule.py contains functions that fills in the default values
* ValidatorModule.py contains functions that validates values in the manifest
The source code for DC is in the slim source gate. To get a copy of the slim source gate
{code}
hg clone ssh://anon@opensolaris.org/hg/caiman/slim_source
{code}
h3. usr/src/cmd/distro_const
* code for the main DC program
* distro_const.py is installed as /usr/bin/distro_const
* Most of the code is installed as the python module in /usr/lib/python2.4/vendor-packages/osol_install/distro_const
h3. usr/src/cmd/distro_const/utils
* common finalizer scripts and configurations
* installed in /usr/share/distro_const
h3. usr/src/cmd/distro_const/slim_cd
* Slim CD specific finalizer scripts and configurations
* installed in /usr/share/distro_const/slim_cd
h3. usr/src/cmd/distro_const/auto_install
* Automated Installer specific finalizer scripts and configurations
* installed in /usr/share/distro_const/auto_install
h1. Dependency on other Install modules
The Distribution Constructor application uses other install modules
h3. The Target Instantiation Module (TI)
* DC uses the TI module to create UFS and ZFS file systems.
* TI module has a special module for DC, usr/src/lib/libti/dcm.c
* DC uses TI via the C to python interface provided in usr/src/lib/libti_pymod
* All the DC code that calls the TI module are in usr/src/cmd/distro_const/DC_ti.py
* [TI TOI presentation|http://www.opensolaris.org/os/project/caiman/files/toi_td_ti_tm_orch.pdf], pages 18-33, page 25 is about the DC module
h3. The Transfer Module (TM)
* TM module is in Python
* It has 2 modes of operation.
** TM_PERFORM_CPIO
** TM_PERFORM_IPS
* The DC application itself only uses the IPS mode for populating the package image area, and setting IPS related properties. The DC calls all the TM calls in usr/src/cmd/distro_const/DC_tm.py
* The usr/src/cmd/distro_const/utils/bootroot_initialize.py finalizer script uses the TM_PERFORM_CPIO mode to copy files into the boot_archive.
* [TM TOI presentation|http://www.opensolaris.org/os/project/caiman/files/toi_td_ti_tm_orch.pdf], pages 34-43
h3. The XML parser
* XML parser is used for processing the manifest
* Both the command line and the python interface provided by the XML parser module are used by the DC to retrieve values from the manifest.
* [XML parser TOI presentation|http://wikis.sun.com/display/OSOLInstall/XML+PreProcessor+and+Parser]
h3. The finalizer engine
* It's a Python module located in usr/src/lib/install_utils/finalizer.py
* It's calls scripts and programs that are queued up in the order that they are registered
* A pre-defined set of argument(s) can be passed into the finalizer module so all those arguments are passed to each scripts and programs when called.
* arguments to the scripts and programs can be specified at the same time programs are registered
* DC registers scripts specified in the manifest into the finalizer engine to mold the final output for different image types.
h1. Major components of DC
h3. Diagram of DC program flow
!DC_arch_diagram.jpg!
h3. checkpointing
* Provides the ability to start or pause at a certain step in the build process
* The process of populating the pkg image area with packages specified in the manifest is the first step. Each of the finalizer scripts specified in the manifest made up all the subsequent steps.
* Implemented using ZFS snapshot
** The <build_area>/build_data dataset is snapshot for each step
** <datasetname>@step_<step name>
** Rolls back if you resume at that step
* .step_<step_name> files
** One file for each saved step
** Located at the build area
** Copy of the manifest file
** When determining which steps are available to be resumed from, the list of .step_<step_name> files are checked
* finalizer_checkpoint.py and finalizer_rollback.py are used for doing checkpointing for finalizer scripts
* All code related to checkpoint handling are in DC_checkpoint.py
h3. Logging
* Log files for each DC run is timestamped and are located in <build_area>/logs
* The detail log contains all outputs and errors from all commands and programs executed by DC
* The simple log contains only errors and warnings from commands and programs executed by DC
* The console output when DC is executed is the same as the simple log
* Logging in DC uses python logging
* Logging is initialized in dc_utils.py
h3. Bootroot
* Bootroot is created with a series of finalizer scripts
* The staging area for the bootroot is at <work_area>/bld_data/bootroot
* For the Slim CD, the series of finalizer scripts are:
** */usr/share/distro_const/bootroot_initialize.py*
Populates the bootroot with staging area with content specified in the manifest
** */usr/share/distro_const/slim_cd/slimcd_bootroot_configure*
Slim CD specific configuration needed to the bootroot
** */usr/share/distro_const/bootroot_configure*
Special configuration for the bootroot, such as importing SMF services, creating symlinks
** */usr/share/distro_const/bootroot_archive.py*
Calculate size of the bootroot, create an UFS archive of the configured bootroot content, and compress it.
h3. Manifest defaults and validation
* Utilizes the XML parsing module
* DC-manifest.rng specifies format of the manifest
* DC-manifest.defval.xml specifies the default values for different manifest fields
* DefaultsModule.py contains functions that fills in the default values
* ValidatorModule.py contains functions that validates values in the manifest