From 9b2c586aaddb23198fa3cde0ce1aef64e36657a7 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 16 Oct 2012 11:14:36 -0700 Subject: documentation: dev-manual - lttng and Git workflow changes * Updates to the Git Workflow section based on feedback from Darren Hart. These changes simplify the flow and make it generic. * Updates to the lttng user space tool used from within Eclipse. The legacy version of the tool is no longer supported so it had to be edited out of the description and replaced with the 2.0 version. (From yocto-docs rev: 81d2b79035fc99f92364bfef2c76076738cbaa52) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/dev-manual/dev-manual-model.xml | 144 +++++++++++++------------- 1 file changed, 74 insertions(+), 70 deletions(-) diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml index b61eeb0678..669623bc7f 100644 --- a/documentation/dev-manual/dev-manual-model.xml +++ b/documentation/dev-manual/dev-manual-model.xml @@ -1271,44 +1271,48 @@ directory. . The oprofile-server is installed by default on the core-image-sato-sdk image. - Lttng-ust: Selecting this tool runs - usttrace on the remote target, transfers the output data back - to the local host machine, and uses the lttng Eclipse plug-in to - graphically display the output. - For information on how to use lttng to trace an application, see - . - For Application, you must supply the absolute path name of the - application to be traced by user mode lttng. - For example, typing /path/to/foo triggers - usttrace /path/to/foo on the remote target to trace the - program /path/to/foo. - Argument is passed to usttrace - running on the remote target. - Before you use the lttng-ust tool, you need to setup - the lttng Eclipse plug-in and create a lttng - project. + Lttng2.0 ust trace import: + Selecting this tool transfers the remote target's + Lttng tracing data back to the local host machine + and uses the Lttng Eclipse plug-in to graphically + display the output. + For information on how to use Lttng to trace an application, + see . + Do not use Lttng-user space (legacy) tool. + This tool no longer has any upstream support. + + Before you use the Lttng2.0 ust trace import tool, + you need to setup the Lttng Eclipse plug-in and create a + Tracing project. Do the following: - Follow the instructions from the - Linux Tools Projec/LTTng2/User Guide - to download and install the lttng parser library. - Select Window -> Open Perspective -> Other - and then select LTTng. + and then select Tracing. Click OK to change the Eclipse perspective - into the LTTng perspective. - Create a new LTTng project by selecting + into the Tracing perspective. + Create a new Tracing project by selecting File -> New -> Project. - Choose LTTng -> LTTng Project. - Click YoctoTools -> lttng-ust to start user mode - lttng on the remote target. - - After the output data has been transferred from the remote target back to the local - host machine, new traces will be imported into the selected LTTng project. - Then you can go to the LTTng project, right click the imported - trace, and set the trace type as the LTTng kernel trace. - Finally, right click the imported trace and select Open - to display the data graphically. + Choose Tracing -> Tracing Project. + + Generate your tracing data on the remote target. + + Click + Yocto Project Tools -> Lttng2.0 ust trace import + to start the data import process. + Specify your remote connection name. + For the Ust directory path, specify the location of + your remote tracing data. + Make sure the location ends with ust (e.g. + /usr/mysession/ust. + Click OK to complete the import process. + The data is now in the local tracing project you created. + Right click on the data and then use the menu to + Select Trace Type... -> Common Trace Format -> Generic CTF Trace + to map the tracing type. + Right click the mouse and select Open + to bring up the Eclipse Lttng Trace Viewer so you + view the tracing data. + PowerTOP: Selecting this tool runs powertop on the remote target machine and displays the results in a new view called powertop. @@ -1540,10 +1544,12 @@ directory. Again, assuming top-level Source Directory named poky and a default build directory of poky/build, the - following is the work directory for the acl package that is being + following are the work and temporary source directories, respectively, + for the acl package that is being built for a MIPS-based device: ~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2 + ~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2/acl-2.2.51 @@ -1593,7 +1599,7 @@ directory. Change Your Working Directory: You need to be in the directory that has the temporary source code. That directory is defined by the - S + S variable. Create a New Patch: Before modifying source code, you need to create a new patch. @@ -1602,14 +1608,16 @@ directory. $ quilt new my_changes.patch Notify Quilt and Add Files: - After creating the patch, you need to notify Quilt about the files you will - be changing. - Add the files you will be modifying into the patch you just created: + After creating the patch, you need to notify Quilt about the files + you plan to edit. + You notify Quilt by adding the files to the patch you just created: $ quilt add file1.c file2.c file3.c - + + Edit the Files: - Make the changes to the temporary source code. + Make your changes in the temporary source code to the files you added + to the patch. Test Your Changes: Once you have modified the source code, the easiest way to test your changes is by calling the compile task as shown in the following example: @@ -1641,7 +1649,9 @@ directory. subdirectory of the source (S) directory. Copy the Patch File: For simplicity, copy the patch file into a directory named files, - which you can create in the same directory as the recipe. + which you can create in the same directory that holds the recipe + (.bb) file or the + append (.bbappend) file. Placing the patch here guarantees that the OpenEmbedded build system will find the patch. Next, add the patch into the @@ -1687,33 +1697,24 @@ directory. Change Your Working Directory: You need to be in the directory that has the temporary source code. That directory is defined by the - S - variable. - If you are working with a kernel, you need to be in the - ${S}/linux directory. + S + variable. If needed, initialize a Git Repository: - If you are not already in a Git repository, use the - git init command to initialize a new local repository - that is based on the work directory: + If the recipe you are working with does not use a Git fetcher, + you need to set up a Git repository as follows: $ git init - - Stage all the files: - Use the git add * command to stage all the files in the source - code directory so that they can be committed: - $ git add * - - Commit the Source Files: - Use the git commit command to initially commit all the files in - the work directory: - $ git commit + The above Git commands initialize a Git repository that is based on the + files in your current working directory, stage all the files, and commit + the files. At this point, your Git repository is aware of all the source code files. - Any edits you now make to files will be tracked by Git. + Any edits you now make to files can be committed later and will be tracked by + Git. Edit the Files: - Make the changes to the temporary source code. + Make your changes to the temporary source code. Test Your Changes: Once you have modified the source code, the easiest way to test your changes is by calling the compile task as shown in the following example: @@ -1725,8 +1726,8 @@ directory. If you find problems with your code, you can just keep editing and re-testing iteratively until things work as expected. All the modifications you make to the temporary source code - disappear once you -c clean or - -c cleanall with BitBake for the package. + disappear once you -c clean, -c cleansstate, + or -c cleanall with BitBake for the package. Modifications will also disappear if you use the rm_work feature as described in the "Building an Image" @@ -1742,11 +1743,9 @@ directory. Stage the Modified Files: Use the git add command to stage the changed files so they - can be committed as follows. - Again, for this discussion assume the files changed are in the linux - directory: + can be committed as follows: - $ git add <somepath>/file1.c <somepath>/file2.c <somepath>/file3.c + $ git add file1.c file2.c file3.c Commit the Staged Files and View Your Changes: Use the git commit command to commit the changes to the @@ -1754,9 +1753,11 @@ directory. Once you have committed the files, you can use the git log command to see your changes: - $ git commit + $ git commit -m "<commit-summary-message>" $ git log - + + The name of the patch file created in the next step is based on your + commit-summary-message. Generate the Patch: Once the changes are committed, use the git format-patch command to generate a patch file: @@ -1768,11 +1769,14 @@ directory. At this point, the patch file has all your edits made to the file1.c, file2.c, and file3.c files. - You can find the resulting patch file in the current directory. + You can find the resulting patch file in the current directory and it + is named according to the git commit summary line. The patch file ends with .patch. Copy the Patch File: For simplicity, copy the patch file into a directory named files, - which you can create in the same directory as the recipe. + which you can create in the same directory that holds the recipe + (.bb) file or the + append (.bbappend) file. Placing the patch here guarantees that the OpenEmbedded build system will find the patch. Next, add the patch into the -- cgit v1.2.3-54-g00ecf