<p>I had this thought as well. What conventions / standards to make users jobs easier when integrating/reviewing/certifying rtems?<br>
-gedare</p>
<div class="gmail_quote">On Dec 4, 2012 1:50 PM, "Jon Brinkmann" <<a href="mailto:brinkmann@nmsu.edu">brinkmann@nmsu.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Since NASA and some of it's contractors use RTEMs, we need to include their<br>
standards @ <a href="http://lars-lab.jpl.nasa.gov/" target="_blank">http://lars-lab.jpl.nasa.gov/</a><br>
<br>
Jon<br>
<br>
On Tue, Dec 04, 2012 at 01:31:32PM -0500, Gedare Bloom wrote:<br>
> While I'm not so sure that having two coding styles is a great idea, I<br>
> think it will be easiest to maintain the existing "RTEMS Style" in the<br>
> score. I'd be on-board with adopting the freebsd style guide to fit RTEMS,<br>
> I think that a codified set of rules will be nice to have. Joel had an<br>
> Asciidoc floating around that described the RTEMS Style, but it wasn't<br>
> complete.<br>
><br>
> Some of the BSD rules won't make sense in RTEMS, and some will need to be<br>
> modified to fit, e.g. "use chains" instead of "use queues", and the API<br>
> visibility rules.<br>
><br>
> The RTEMS Style may not be standard, but I don't think it would be hard to<br>
> codify to apply to all of RTEMS.  Perhaps adopting BSD rules where the<br>
> RTEMS style is "silent" could help there, but there are conflicts between<br>
> the BSD and RTEMS style, so merging the two would not be clean.<br>
><br>
> Rules that conflict explicitly between BSD and RTEMS style include:<br>
> * use of tabs<br>
> * no space after ( and before ) in if/for/etc statements<br>
> * variable declaration name alignment<br>
><br>
> Points where RTEMS style implicitly conflicts with BSD include:<br>
> * avoid typedefs<br>
> * \ aligned to the far right<br>
> * function type on line before function name<br>
> * variable declarations sorted by size and alphabet<br>
><br>
> It might also be nice to define rules about assembly, both inline and in .S<br>
> files.<br>
><br>
> -Gedare<br>
><br>
><br>
> On Tue, Dec 4, 2012 at 12:50 PM, Sebastian Huber <<br>
> <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br>
><br>
> > Hello,<br>
> ><br>
> > we need a formal coding style for RTEMS since otherwise it is very hard<br>
> > for newcomers to do things right.  My first question to this topic is this:<br>
> ><br>
> > Do we want to use two coding styles? One for the score (cpukit/{score,<br>
> > rtems, posix, sapi}) and one for other parts (like shell, test suite, BSPs,<br>
> > etc.).<br>
> ><br>
> > The score has a consistent coding style.  Here we need only a good<br>
> > description.  The bad thing of the score coding style is that it is<br>
> > somewhat special and not in widespread use outside of RTEMS.<br>
> ><br>
> > Other parts in RTEMS have no consistent coding style.  I suggest to use a<br>
> > well established coding style for these and enforce it for new files.<br>
> >  Since we already use large parts of BSD (old and new network stack, USB<br>
> > stack, ATA stack) this is a natural choice.<br>
> ><br>
> > <a href="http://www.freebsd.org/cgi/**man.cgi?query=style&apropos=0&**" target="_blank">http://www.freebsd.org/cgi/**man.cgi?query=style&apropos=0&**</a><br>
> > sektion=0&manpath=FreeBSD+9.0-**RELEASE&arch=default&format=**html<<a href="http://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html" target="_blank">http://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html</a>><br>

> ><br>
> > Another one is the Linux coding style.<br>
> ><br>
> > <a href="http://www.kernel.org/doc/**Documentation/CodingStyle" target="_blank">http://www.kernel.org/doc/**Documentation/CodingStyle</a><<a href="http://www.kernel.org/doc/Documentation/CodingStyle" target="_blank">http://www.kernel.org/doc/Documentation/CodingStyle</a>><br>

> ><br>
> > For the GNU style let me quote the document above:<br>
> ><br>
> > "First off, I'd suggest printing out a copy of the GNU coding standards,<br>
> > and NOT read it. Burn them, it's a great symbolic gesture."<br>
> ><br>
> > --<br>
> > Sebastian Huber, embedded brains GmbH<br>
> ><br>
> > Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany<br>
> > Phone   : <a href="tel:%2B49%2089%2018%2090%2080%2079-6" value="+4989189080796">+49 89 18 90 80 79-6</a><br>
> > Fax     : <a href="tel:%2B49%2089%2018%2090%2080%2079-9" value="+4989189080799">+49 89 18 90 80 79-9</a><br>
> > E-Mail  : sebastian.huber@embedded-**<a href="http://brains.de" target="_blank">brains.de</a><<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>><br>
> > PGP     : Public key available on request.<br>
> ><br>
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
> ><br>
> > ______________________________**_________________<br>
> > rtems-devel mailing list<br>
> > <a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
> > <a href="http://www.rtems.org/mailman/**listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/**listinfo/rtems-devel</a><<a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a>><br>

> ><br>
<br>
> _______________________________________________<br>
> rtems-devel mailing list<br>
> <a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
> <a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
</blockquote></div>