RTEMS Software Engineering Handbook (5.0.0 (master)).

COPYRIGHT (c) 1988 - 2015.

On-Line Applications Research Corporation (OAR).

COPYRIGHT (c) 2016-2018.

RTEMS Foundation, The RTEMS Documentation Project

License:

Creative Commons Attribution-ShareAlike 4.0 International Public License

https://creativecommons.org/licenses/by-sa/4.0/legalcode

The authors have used their best efforts in preparing this material. These efforts include the development, research, and testing of the theories and programs to determine their effectiveness. No warranty of any kind, expressed or implied, with regard to the software or the material contained in this document is provided. No liability arising out of the application or use of any product described in this document is assumed. The authors reserve the right to revise this material and to make changes from time to time in the content hereof without obligation to notify anyone of such revision or changes.

The RTEMS Project is hosted at http://www.rtems.org/. Any inquiries concerning RTEMS, its related support components, or its documentation should be directed to the Community Project hosted at http://www.rtems.org/.

RTEMS Online Resources

Home	https://www.rtems.org/
Developers	https://devel.rtems.org/
Documentation	https://docs.rtems.org/
Bug Reporting	https://devel.rtems.org/query
Mailing Lists	https://lists.rtems.org/
Git Repositories	https://git.rtems.org/

• 1. Preface
• 2. Introduction to Pre-Qualification
• 3. RTEMS Stakeholders
  • 3.1. Qualification - Stakeholder Involvement
• 4. Software Development Management
  • 4.1. Software Development (Git Users)
    • 4.1.1. Browse the Git Repository Online
    • 4.1.2. Using the Git Repository
    • 4.1.3. Making Changes
    • 4.1.4. Working with Branches
    • 4.1.5. Viewing Changes
    • 4.1.6. Reverting Changes
    • 4.1.7. git reset
    • 4.1.8. git revert
    • 4.1.9. Merging Changes
    • 4.1.10. Rebasing
    • 4.1.11. Accessing a developer’s repository
    • 4.1.12. Creating a Patch
    • 4.1.13. Submitting a Patch
    • 4.1.14. Configuring git send-email to use Gmail
    • 4.1.15. Sending Email
    • 4.1.16. Troubleshooting
    • 4.1.17. Manage Your Code
    • 4.1.18. Private Servers
    • 4.1.19. Learn more about Git
  • 4.2. Software Development (Git Writers)
    • 4.2.1. SSH Access
    • 4.2.2. Personal Repository
    • 4.2.3. Create a personal repository
      • 4.2.3.1. Check your setup
      • 4.2.3.2. Push commits to personal repo master from local master
      • 4.2.3.3. Push a branch onto personal repo
      • 4.2.3.4. Update from upstream master (RTEMS head)
    • 4.2.4. GIT Push Configuration
    • 4.2.5. Pull a Developer’s Repo
    • 4.2.6. Committing
      • 4.2.6.1. Ticket Updates
      • 4.2.6.2. Commands
    • 4.2.7. Pushing Multiple Commits
    • 4.2.8. Ooops!
  • 4.3. Coding Standards
    • 4.3.1. Coding Conventions
      • 4.3.1.1. Source Documentation
      • 4.3.1.2. Licenses
      • 4.3.1.3. Language and Compiler
      • 4.3.1.4. Formatting
      • 4.3.1.5. Readability
      • 4.3.1.6. Robustness
      • 4.3.1.7. Portability
      • 4.3.1.8. Maintainability
      • 4.3.1.9. Performance
      • 4.3.1.10. Miscellaneous
      • 4.3.1.11. Layering
      • 4.3.1.12. Exceptions to the Rules
      • 4.3.1.13. Tools
    • 4.3.2. Eighty Character Line Limit
      • 4.3.2.1. Breaking long lines
    • 4.3.3. Deprectating Interfaces
    • 4.3.4. Doxygen Recommendations for BSPs
      • 4.3.4.1. BSP Basics
      • 4.3.4.2. Common Features Found In BSPs
      • 4.3.4.3. Shared Features
      • 4.3.4.4. Rationale
      • 4.3.4.5. The Structure of the bsps/ directory
      • 4.3.4.6. Doxygen
      • 4.3.4.7. Doxygen Basics
      • 4.3.4.8. Doxygen Headers
      • 4.3.4.9. The @defgroup Command
      • 4.3.4.10. The @ingroup Command
      • 4.3.4.11. The @brief Command
      • 4.3.4.12. The Two Types of Doxygen Headers
      • 4.3.4.13. Generating Documentation
      • 4.3.4.14. Doxygen in bsps/
      • 4.3.4.15. Group Naming Conventions
      • 4.3.4.16. Where to place @defgroup
      • 4.3.4.17. @defgroups for CPU Architectures and Shared Directories
      • 4.3.4.18. @defgroups for BSPs
      • 4.3.4.19. @defgroups for Everything Else
      • 4.3.4.20. Look Common Features Implemented
      • 4.3.4.21. Check out the Makefile
      • 4.3.4.22. Start with a .h, and look for files that include it
      • 4.3.4.23. Files with similar names
      • 4.3.4.24. Where to place @ingroup
      • 4.3.4.25. @ingroup in the first type of Doxygen Header
      • 4.3.4.26. @ingroup in the second type of Doxygen Header
      • 4.3.4.27. @ingroup for shared code
    • 4.3.5. General Doxygen Recommentations
      • 4.3.5.1. Doxygen Best Practices
      • 4.3.5.2. Special Notes for Google Code-in Students
      • 4.3.5.3. Header File Example
      • 4.3.5.4. Header blocks
      • 4.3.5.5. Header guard
      • 4.3.5.6. Includes
      • 4.3.5.7. Using @defgroup for group definitions
      • 4.3.5.8. enum and struct
      • 4.3.5.9. Using @name for organization
      • 4.3.5.10. Declaring functions
      • 4.3.5.11. Ending the file
      • 4.3.5.12. Source File Example
      • 4.3.5.13. Files
      • 4.3.5.14. Functions
      • 4.3.5.15. Doxyfile Hints
      • 4.3.5.16. GCC Attributes
    • 4.3.6. Boilerplate File Header
    • 4.3.7. Generating a Tools Patch
    • 4.3.8. Naming Rules
      • 4.3.8.1. General Rules
  • 4.4. Change Management
  • 4.5. Issue Tracking
    • 4.5.1. Filing a Change Request or Problem Report
  • 4.6. Why Contribute?
    • 4.6.1. Common Questions and Answers
• 5. Software Test Plan Assurance and Procedures
  • 5.1. Testing and Coverage
    • 5.1.1. Test Suites
      • 5.1.1.1. Legacy Test Suites
    • 5.1.2. RTEMS Tester
• 6. Software Release Management
  • 6.1. Software Change Report Generation
  • 6.2. Version Description Document (VDD) Generation
• 7. User’s Manuals
  • 7.1. Documentation Style Guidelines
• 8. Licensing Requirements
• 9. Appendix: Core Qualification Artifacts/Documents

• Index