首先rtems公司强烈鼓励开发者进行代码贡献，错误修复，优化，新功能，文档更新和任何其他有用的更改。

所有的贡献都必须满足一些法律要求和编码公约。比如代码编写语言，编译器等。详见链接：

https://devel.rtems.org/wiki/Developer/Coding/Conventions

法律公约：

在纯GPL下发布的代码与RTEMS许可证不兼容，因此不应被添加到RTEMS源代码树中。RTEMS中提供的代码段附带了各种许可证，但所有许可证都应与源自GPL第2版（但不完全相同）的RTEMS主许可证兼容。

提交改动：

对RTEMS所做的每一次更改都必须有几条信息，然后才能正确评估它。

首先是描述：

对于新功能，请包括功能和您的设计/实现的描述。如果你不能遵循RTEMS编码规范的建议，你应该包括为什么的理由。 如果您正在从另一个免费软件项目提交代码端口，那么该代码不应重新格式化为RTEMS。 它需要保持尽可能接近原始源，以便于以后的更新努力。

然后是测试：

我们鼓励您使用尽可能多的主机和目标组合来测试更改。 除了使用真实的硬件，您可以使用模拟器来增加测试覆盖率。当选择目标测试一个补丁，尝试练习代码的各个方面，你正在改变各种RTEMS配置。 还要记住，RTEMS支持具有16位，32位和64位整数的目标。 这意味着大多数RTEMS源代码树必须在所有这些目标上构建没有警告。

接着是补丁：

补丁是一个包含旧版本和新版本代码之间的区别的文本文件。对当前开发版本进行补丁会比稳定版本的补丁更好，除非你的补丁被打算作为一个版本分支的bug修复候选。

如何创建一个补丁链接：https://devel.rtems.org/wiki/Developer/Git/Users#CreatingaPatch

如果您没有Git存储库可用，那么您可以使用diff程序通过比较未修改的RTEMS和包含您的更改的版本与diff -up rtems rtems-new来创建补丁，并将输出重定向到文件。

我们喜欢以纯文本形式发布的补丁。 如果补丁太大发布它gzipped是可以接受的，但它会更好作为一个分支，可以拉/审查。 将补丁提交到邮件列表。

最后是提交：

 所有补丁和相关讨论应发送到rtems-devel邮件列表。 有关RTEMS Git存储库的更多信息，请参阅Git。

如果您在一个月左右没有收到补丁的回复，请发送后续电子邮件。 补丁有时会从裂缝中掉落。 请确保在原始提交的邮件列表存档中包含条目的URL。