Difference between revisions of "TSK Developer's Guide"

From SleuthKitWiki
Jump to: navigation, search
(Initial version created.)
 
(8 intermediate revisions by one user not shown)
Line 1: Line 1:
This page contains information on developing code for TSK, Autopsy, and related tools. If you are looking for a guide that helps to incorporate the TSK library into your tools, then refer to the [[Library User's Guide]].  
+
This page contains technical information on developing code for [[TSK]]. If you are looking for a guide that helps to incorporate the TSK library into your tools, then refer to the [[TSK Library User's Guide]].  
  
 
This page is a work in progress and more information will be posted.  Here are some starting points.  
 
This page is a work in progress and more information will be posted.  Here are some starting points.  
* The [http://lists.sourceforge.net/lists/listinfo/sleuthkit-developers Sleuth Kit Developers] list exists to discuss the development of the tools.  Subscribe to ask and answer questions.  
+
* The [[Developer Guidelines]] define how code and patches can be submitted and incorporated into the distribution.  
 +
* The [[sleuthkit-developers]] list exists to discuss the development of the tools.  Subscribe to ask and answer questions.  
 
* If you want to contribute documentation, then refer to the [http://www.sleuthkit.org/support.php Support] page.  
 
* If you want to contribute documentation, then refer to the [http://www.sleuthkit.org/support.php Support] page.  
  
 +
= What To Do? =
 +
If you are looking for ideas on how you can contribute, then you may want to refer to the feature request and bug [[trackers]].  They contain ideas that people have for the tools or bugs that need to be fixed.
  
= Submitting Code / Patches =
 
To contribute code or patches to the project, send e-mail to the [http://lists.sourceforge.net/lists/listinfo/sleuthkit-developers sleuthkit-developers] list. Include the new code or diffs of the changes. Code submissions should follow the TSK error handling, Unicode, and other conventions. To make the changes as portable as possible, use generic methods and libraries and avoid ones that are platform-specific. A more detailed list of guidelines is being developed.
 
  
To make diffs of the changes, run the following command on a Unix system (or from cygwin on Windows):
+
= Technical Details =
 +
The source code is stored in a [http://github.org/ github] repository. You can get the latest source tree from [https://github.com/sleuthkit/sleuthkit https://github.com/sleuthkit/sleuthkit].  The latest code is in the <tt>master</tt> branch.  There are branches for the major release branches (3.1, 3.2, etc.) and tags for each release. The github repository contains the history from the previous subversion repository.  Note that the previous subversion repository was created right before the 3.0.0 release and does not contain the previous CVS history.
  
<code>
 
% diff -Nru sleuthkit-old sleuthkit-new > changes.patch
 
</code>
 
  
The patches and code contributions will be reviewed and incorporated into the main development if they are approved. It is also helpful to submit test images and test cases that can be used to test the new code.
+
= Coding Standards =
 +
Here are the standards that I have been trying to maintain in TSK for the past few years.
  
= Guidelines =
+
* Spaces instead of tabs
To be defined...
+
* The C code uses GNU indent to handle the formatting (just do a 'make indent' in the directory).
 +
* I have no good indenting solution for C++ code (GNU indent makes UGLY C++ code)
 +
* C++ fields start with "m_"
 +
* Arguments to C/C++ functions/methods start with "a_".  
 +
* C names use underscores
 +
* C structs are all upper case
 +
* C variable names start with lower case
 +
* C++ names use camel case
 +
* C++ Classes start with a capital letter
 +
* C++ objects start with a lower case letter
 +
 
 +
Not all of TSK is up to date on these standards as I have been updating them as I fix bugs and such.
 +
 
 +
= Design Docs =
 +
* [[Design Documents]]

Revision as of 21:06, 5 June 2012

This page contains technical information on developing code for TSK. If you are looking for a guide that helps to incorporate the TSK library into your tools, then refer to the TSK Library User's Guide.

This page is a work in progress and more information will be posted. Here are some starting points.

  • The Developer Guidelines define how code and patches can be submitted and incorporated into the distribution.
  • The sleuthkit-developers list exists to discuss the development of the tools. Subscribe to ask and answer questions.
  • If you want to contribute documentation, then refer to the Support page.

What To Do?

If you are looking for ideas on how you can contribute, then you may want to refer to the feature request and bug trackers. They contain ideas that people have for the tools or bugs that need to be fixed.


Technical Details

The source code is stored in a github repository. You can get the latest source tree from https://github.com/sleuthkit/sleuthkit. The latest code is in the master branch. There are branches for the major release branches (3.1, 3.2, etc.) and tags for each release. The github repository contains the history from the previous subversion repository. Note that the previous subversion repository was created right before the 3.0.0 release and does not contain the previous CVS history.


Coding Standards

Here are the standards that I have been trying to maintain in TSK for the past few years.

  • Spaces instead of tabs
  • The C code uses GNU indent to handle the formatting (just do a 'make indent' in the directory).
  • I have no good indenting solution for C++ code (GNU indent makes UGLY C++ code)
  • C++ fields start with "m_"
  • Arguments to C/C++ functions/methods start with "a_".
  • C names use underscores
  • C structs are all upper case
  • C variable names start with lower case
  • C++ names use camel case
  • C++ Classes start with a capital letter
  • C++ objects start with a lower case letter

Not all of TSK is up to date on these standards as I have been updating them as I fix bugs and such.

Design Docs