|
|
|
How To Contribute
|
|
|
|
=================
|
|
|
|
|
|
|
|
If you are interested in contributing to Xenomai here are some helpful hints on
|
|
|
|
how to get started. Start small, then progress as you get your feet wet. There
|
|
|
|
is no such thing as a minor contribution, there is no shame in making mistakes.
|
|
|
|
A contributor who submits a perfectible one-liner surely advances the project
|
|
|
|
further than any smart lurker.
|
|
|
|
|
|
|
|
Things you will need:
|
|
|
|
|
|
|
|
- Git
|
|
|
|
- GCC for your platform
|
|
|
|
- Xenomai link:Getting_The_Xenomai_Code[source code]
|
|
|
|
- Linux tree patched with the link:Getting_The_I_Pipe_Patch[I-pipe]
|
|
|
|
- Autotools
|
|
|
|
- Access to the https://www.xenomai.org/mailman/listinfo/xenomai/[Xenomai mailing list]
|
|
|
|
|
|
|
|
Getting Set up:
|
|
|
|
--------------
|
|
|
|
Before starting to contribute you should have read the following documents:
|
|
|
|
|
|
|
|
- link:Home[Getting Started]
|
|
|
|
- link:Getting_The_Xenomai_Code[Getting The Code]
|
|
|
|
- link:Installing_Xenomai_3_X[Installing Xenomai]
|
|
|
|
- link:Building_Applications_For_Xenomai_3_X[Building Applications]
|
|
|
|
- link:Running_Applications_For_Xenomai_3_X[Running Applications]
|
|
|
|
- link:Getting_Help[Getting Help]
|
|
|
|
|
|
|
|
Workflow
|
|
|
|
--------
|
|
|
|
The above mentioned documents will guide you through acquiring the source code,
|
|
|
|
getting the development environment set up, and building Xenomai. If you are
|
|
|
|
having issues getting your development environment setup or built, please review
|
|
|
|
the documents or consult the Xenomai mailing list.
|
|
|
|
|
|
|
|
As a guideline for what branch to work on, the next branch is for new
|
|
|
|
core features, new CPU architecture ports or large scale changes. Only
|
|
|
|
bug fixes and possibly new drivers should be pushed to stable-*
|
|
|
|
branches. Any change that would prevent applications based on earlier
|
|
|
|
releases from the same branch from running on later ones should not go
|
|
|
|
into stable-* branches. For example, an application built for the
|
|
|
|
3.0.2 release must build with no modifications on 3.0.6.
|
|
|
|
|
|
|
|
Generally speaking, the kernel part of Xenomai (aka Cobalt core) aims
|
|
|
|
at following the standard kernel coding style.
|
|
|
|
|
|
|
|
After you make your changes, one thing to keep in mind is that when you
|
|
|
|
submit your patches to the the mailing list each patch should address exactly one
|
|
|
|
issue. You may want to make one commit for every patch you wish to generate. This may
|
|
|
|
be a good workflow if you are addressing more than one issue during development.
|
|
|
|
|
|
|
|
When you are done development and testing you are ready to generate patches.
|
|
|
|
Use git format-patch to create a patch (or patch set) that you can submit for review.
|
|
|
|
|
|
|
|
Once you have generated your patch (or patches) you need to send them off to the
|
|
|
|
mailing list for review. This can be done using git send-email. This may be
|
|
|
|
slightly tricky to set up. I suggest googling for the best way to set this up in
|
|
|
|
your gitconfig file that best suits your email provider and authentication method.
|
|
|
|
Once it is configured you can submit your patch to the mailing list.
|
|
|
|
|
|
|
|
|
|
|
|
|