<div dir="ltr"><div dir="auto">Sir, can you please clarify a little bit what does "each question needs to be a section heading of some level" mean , because sir I have used  this "-----" line below every question which is a symbol used for showing the sentence as a heading in sphinx document and after building the questions are automatically shown as 2.10.1, 2.10.2 ... (upto total questions).  </div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Apr 4, 2021, 5:05 AM Chris Johns <<a href="mailto:chrisj@rtems.org" rel="noreferrer" target="_blank">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 3/4/21 6:25 am, Gedare Bloom wrote:<br>
> On Fri, Apr 2, 2021 at 12:19 PM Ayushman Mishra<br>
> <<a href="mailto:ayushvidushi01@gmail.com" rel="noreferrer noreferrer" target="_blank">ayushvidushi01@gmail.com</a>> wrote:<br>
>><br>
>> ---<br>
>>  user/bld/index.rst               |   2 +<br>
>>  user/overview/index.rst          |   2 +<br>
>>  user/start/faq.rst               | 295 +++++++++++++++++++++++++++++++<br>
>>  user/start/index.rst             |   1 +<br>
>>  user/support/contrib.rst         |  96 +---------<br>
>>  user/support/support-project.rst |   2 +<br>
>>  6 files changed, 303 insertions(+), 95 deletions(-)<br>
>>  create mode 100644 user/start/faq.rst<br>
>><br>
>> diff --git a/user/bld/index.rst b/user/bld/index.rst<br>
>> index ebedf5a..0cccde2 100644<br>
>> --- a/user/bld/index.rst<br>
>> +++ b/user/bld/index.rst<br>
>> @@ -284,6 +284,8 @@ example configuration file, building of the tests is enabled for the<br>
>><br>
>>      [riscv/griscv]<br>
>><br>
>> +.. _Migration_from_AutoconfAutomake:<br>
>> +<br>
>>  Migration from Autoconf/Automake<br>
>>  ================================<br>
>><br>
>> diff --git a/user/overview/index.rst b/user/overview/index.rst<br>
>> index 550724a..0703ede 100644<br>
>> --- a/user/overview/index.rst<br>
>> +++ b/user/overview/index.rst<br>
>> @@ -20,6 +20,8 @@ You are someone looking for a real-time operating system.  This document<br>
>><br>
>>  - helps you to build an example application on top of RTEMS.<br>
>><br>
>> +.. _Features:<br>
>> +<br>
>>  Features<br>
>>  ========<br>
>><br>
>> diff --git a/user/start/faq.rst b/user/start/faq.rst<br>
>> new file mode 100644<br>
>> index 0000000..910ef8b<br>
>> --- /dev/null<br>
>> +++ b/user/start/faq.rst<br>
>> @@ -0,0 +1,295 @@<br>
>> +Frequently Asked Questions<br>
>> +==========================<br>
>> +<br>
>> +What is RTEMS ?<br>
> No whitespace before punctuation. "What is RTEMS?"<br>
> <br>
>> +-----------------------------------<br>
>> +<br>
>> +RTEMS is an open source real-time executive which provides a high performance<br>
>> +environment for embedded real-time applications including many features.<br>
>> +<br>
>> +The RTEMS Project is the umbrella term used to describe the collection of<br>
>> +individuals, companies, universities, and research institutions that collectively<br>
>> +maintain and enhance the RTEMS software base.<br>
>> +<br>
>> +RTEMS is designed to support applications with the most stringent real-time<br>
>> +requirements while being compatible with open standards such as POSIX.<br>
>> +RTEMS includes optional functional features such as TCP/IP and various file<br>
>> +systems while still offering minimum executable sizes under 20 KB in useful<br>
>> +configurations.<br>
>> +<br>
>> +:ref:`More Features<Features>`<br>
>> +<br>
>> +Where can I get RTEMS ?<br>
>> +-----------------------------------------------------------------<br>
>> +<br>
>> +:ref:`Downloading RTEMS<QuickStartSources_Released>`<br>
>> +<br>
> <br>
> What happened to:<br>
> How can I pronounce RTEMS like Joel?<br>
> <br>
> <br>
>> +What does RTEMS stand for ?<br>
>> +-------------------------------------------------<br>
>> +<br>
>> +RTEMS is an an acronym for the Real-Time Executive for Multiprocessor Systems.<br>
> "an an" (typo in original wiki page :)<br>
> <br>
>> +<br>
>> +Initially RTEMS stood for the Real-Time Executive for Missile Systems but as it<br>
>> +became clear that the application domains that could use RTEMS extended far<br>
>> +beyond missiles, the "M" changed to mean Military. When maintenance of RTEMS<br>
>> +transferred to OAR, the "M" was changed again to Multiprocessor.<br>
>> +<br>
>> +At one point, there were both Ada and C implementations of RTEMS.<br>
>> +Version 3.2.1 was the last RTEMS version to have implementations in both<br>
>> +languages. Supporting the Classic API Ada implementation was painful and fraught<br>
>> +with compiler specific pitfalls. With version 3.5.x, the POSIX API was added as<br>
>> +the means to support the GNU Ada Translator (GNAT). This effectively eliminated<br>
>> +the need for an implementation in Ada as the C implementation could effectively<br>
>> +support both languages.<br>
>> +<br>
>> +Are there restrictions on the RTEMS License ?<br>
>> +--------------------------------------------<br>
>> +<br>
>> +RTEMS RTEMS is licensed under a combination of permissive licenses and a<br>
>> +modified version of the GNU General Public License (GPL).<br>
>> +For source code "Two Clause BSD” (BSD-2-Clause) and<br>
>> +for documentation CC-BY-SA-4.0 license is preferred.<br>
>> +The modification places no restrictions on the applications which use RTEMS but<br>
>> +protects the interests of those who work on RTEMS.<br>
>> +<br>
>> +`License in RTEMS<br>
>> +<<a href="https://docs.rtems.org/branches/master/eng/" rel="noreferrer noreferrer noreferrer" target="_blank">https://docs.rtems.org/branches/master/eng/</a><br>
>> +license-requirements.html>`__<br>
>> +<br>
> <br>
> add the other questions even if their pages are missing, and maybe add<br>
> a "TBD" stub or something so someone can provide the answers.<br>
> <br>
> Here would be "Are there Export Restrictions? on RTEMS?"<br>
> <br>
>> +What standards are supported by RTEMS?<br>
>> +---------------------------------------------------------<br>
>> +<br>
>> +The original "Classic" RTEMS API is based on the Real-Time Executive Interface<br>
>> +Definition (RTEID) and the Open Real-Time Kernel Interface Definition (ORKID).<br>
>> +RTEMS also includes support for POSIX threads and real-time extensions.<br>
>> +<br>
>> +With the addition of file system infrastructure, RTEMS supports approximately<br>
>> +80% of the POSIX 1003.1b-1996 standard. This standard defines the programming<br>
>> +interfaces of standard UNIX. This means that much source code that works on<br>
>> +UNIX, also works on RTEMS.RTEMS includes a port of the FreeBSD TCP/IP stack and<br>
>> +thus supports BSD sockets. It also includes support for numerous networking<br>
>> +clients (DHCP, TFTP, NFS, etc.) and servers (FTPD, HTTPD, etc.).<br>
>> +<br>
>> +What processors is RTEMS available for ?<br>
>> +----------------------------------------------------------<br>
>> +<br>
>> +:ref:`Architectures in RTEMS<TargetArchitectures>`<br>
> Make this read as a complete sentence:<br>
> <br>
> See :ref:`Architectures in RTEMS<TargetArchitectures>`.<br>
> <br>
>> +<br>
>> +Are there similar commercial products ?<br>
>> +--------------------------------------------<br>
>> +<br>
>> +`Some Real time operating system similar to RTEMS<br>
>> +<<a href="https://en.wikipedia.org/wiki/Comparison_of_real-time_operating_systems" rel="noreferrer noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Comparison_of_real-time_operating_systems</a>>`__<br>
>> +<br>
>> +How can I obtain RTEMS support ?<br>
>> +-----------------------------------------------------<br>
>> +<br>
>> +:ref:`Support in RTEMS<RTEMS_Project_Support>`<br>
>> +<br>
>> +What RTEMS Training Opportunities are available ?<br>
>> +--------------------------------------------------<br>
>> +<br>
>> +`RTEMS Training Opportunities <<a href="https://www.rtems.org/TrainingOpportunities" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.rtems.org/TrainingOpportunities</a>>`__<br>
> ditto<br>
> <br>
>> +<br>
>> +How can I contribute?<br>
>> +-------------------------------------------<br>
>> +<br>
>> +:ref:`Contributions in RTEMS<Contributing>`<br>
> ditto<br>
> <br>
>> +<br>
>> +How are floating point numbers handled ?<br>
>> +---------------------------------------------<br>
>> +<br>
>> +`Floating point support in RTEMS<br>
>> +<<a href="https://docs.rtems.org/branches/master/c-user/task/" rel="noreferrer noreferrer noreferrer" target="_blank">https://docs.rtems.org/branches/master/c-user/task/</a><br>
>> +background.html#floating-point-considerations>`__<br>
> ditto<br>
> <br>
>> +<br>
>> +How do I make a patch ?<br>
>> +--------------------------<br>
>> +<br>
>> +`Creating and sending patch in RTEMS<br>
>> +<<a href="https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch" rel="noreferrer noreferrer noreferrer" target="_blank">https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch</a>>`__<br>
>> +<br>
>> +Why is my executable so big?<br>
>> +-------------------------------------------------------<br>
<br>
I am not sure if anyone has said but each question needs to be a section heading<br>
of some level.<br>
<br>
>> +<br>
>> +There are two primary causes for this. The most common is that you are doing an<br>
>> +ls -l and looking at the actual file size – not the size of the code in the<br>
>> +target image. This file could be in an object format such as ELF or COFF and<br>
>> +contain debug information.<br>
<br>
Please only state ELF. We do not have any COFF targets any more.<br>
<br>
>> If this is the case, it could be an order of magnitude<br>
>> +larger than the required code space. Use the strip command in your cross<br>
>> +toolset to remove debugging information.<br>
>> +<br>
>> +Another alternative is that the executable file is in an ASCII format such as<br>
>> +Motorola Srecords. In this case, there is no debug information in the file<br>
>> +but each byte in the target image requires two bytes to represent. On top of<br>
>> +that, there is some overhead required to specify the addresses where the image<br>
>> +is to be placed in target memory as well as checksum information. In this<br>
>> +case, it is not uncommon to see executable files that are between two and three<br>
>> +times larger than the actual space required in target memory.<br>
>> +<br>
>> +Remember, the debugging information is required to do symbolic debugging with gdb.<br>
>> +Normally gdb obtains its symbolic information from the same file that it gets<br>
>> +the exe- cutable image from. However, gdb does not require that the executable<br>
>> +image and symbolic information be obtained from the same file. So you might want<br>
>> +to create a hello_with_ symbols.exe, copy that file to hello_without_symbols.exe,<br>
>> +and strip hello_without_ symbols.exe. Then gdb would have to be told to read<br>
>> +symbol information from hello_ with_symbols.exe. The gdb command line option<br>
>> +-symbols or command symbol-file may be used to specify the file read for<br>
>> +symbolic information<br>
>> +<br>
>> +What MinGW Tools for Windows are available ?<br>
>> +-------------------------------------------------------------------------<br>
>> +<br>
<br>
Please make sure this is MSYS2 MinGW and not MinGW. MSYS2 MinGW is different to<br>
MinGW. I have not looked at the original MinGW project in years.<br>
<br>
<br>
>> +Windows users can use MinGW based RTEMS tools. These tools will generate the<br>
>> +same application code for RTEMS as the tools on Linux or Cygwin. MinGW tools<br>
>> +use the native Windows runtime rather than access Windows via the POSIX interfac<br>
>> +Cygwin provides. MinGW tools are faster than the Cygwin equivalent and are not<br>
>> +confused by Cygwin mount points. Compiler errors will show a Windows path rather<br>
>> +than a Cygwin path and so do not confuse native Windows editors.<br>
>> +:ref:`Cygwin in windows<Cygwin>`<br>
>> +<br>
>> +The RTEMS MinGW Tools are not currently packaged in installers. <br>
<br>
There should be a section on binary tools which could be referenced ....<br>
<br>
Does the RTEMS Project provide binary packages of tools?<br>
<br>
The RTEMS Project does not provide binary packages of the tools. The project did<br>
at one point but it found more and more resources being devoted to providing an<br>
ever growing number of packages for more and more operating systems and their<br>
variants or distributions.<br>
<br>
The RTEMS Project is focused on open source and providing an efficient means to<br>
build from source means a wide range of host system can be supported. Tools<br>
built on a specific host are correctly matched to that system. The act of<br>
building from source means the user has all the source code used to create an<br>
RTEMS tools and application present on their development system ready to be<br>
archived for long term maintenance.<br>
<br>
Long term maintenance can require building of the tools years later and the RSB<br>
provides a portable means to build old tools on new systems.<br>
<br>
RTEMS Tools can be provided as binary packages externally to the project and<br>
there are some available. The RTEMS project encourages this but those tools and<br>
the support for them needs to be handled by the tools provider.<br>
<br>
The installers<br>
>> +stopped around RTEMS 4.9 when the MinGW tools started to be built as part of<br>
>> +the binary tool package. This means you need to manually step through the<br>
>> +process. It is not difficult, how-ever it is not an easy installer.<br>
>> +<br>
>> +What is Multilib RTEMS ?<br>
>> +-----------------------------------------------------------------<br>
>> +<br>
>> +The multilib process supports building a set of related libraries for a given<br>
>> +target where the individual libraries in the set use different specific<br>
>> +compiler flags (such as flags for code generation options, pre-processor<br>
>> +defines, etc) for the individual libraries. The reason this is needed can be<br>
>> +seen by examining the M68K GCC compiler. That compiler generates code for a<br>
>> +number of processor variants in the M68K family, for example, it can generate<br>
>> +code for the original 68000, the 68040 or a 528x Coldfire. These processors all<br>
>> +use a closely related instruction set, but processor differences mean code<br>
>> +compiled for one may not run on another. GCC provides a special library called<br>
>> +libgcc.a that holds intrinsic functions needed by the compiler. These<br>
>> +intrinsic functions provide "software instructions" (such as non-basic math<br>
>> +support routines) that the processor may not support. However, which functions<br>
>> +GCC considers to be intrinsic should be able to vary within a processor family.<br>
>> +One processor variant will have hardware floating point and another processor<br>
>> +variant will not, and GCC (and RTEMS) should be able to generate efficient code<br>
>> +for each processor variant. When we wish to have different code for a range of<br>
>> +related yet potentially incompatible processors in a family by providing<br>
>> +multiple related libraries we use the multilib process.<br>
>> +<br>
>> +The multilib process extends beyond libgcc.a to libc.a, libm.a, and libstd++.a.<br>
>> +An RTEMS tool set will provide each of these libraries for each of the processor<br>
>> +variants that GCC supports. You can see the multilib information by invoking gcc<br>
>> +with the option '-print-multi-lib'. The output for the M68K tool chain is -<br>
>> +<br>
>> +.. code-block:: none<br>
>> +<br>
>> +    $ m68k-rtems-gcc -print-multi-lib .; m68000;@m68000 m5200;@m5200<br>
>> +    m5206e;@m5206e m528x;@m528x m5307;@m5307 m5407;@m5407 mcpu32;@mcpu32<br>
>> +    m68040;@m68040 m68060;@m68060 msoft-float;@msoft-float<br>
>> +<br>
>> +This output is not easy to read as it is designed for other tools or packages.<br>
>> +<br>
>> +RTEMS core under the cpukit source tree does not reference any BSP specific<br>
>> +details. This allows it to be built as a set of multiple libraries named<br>
>> +librtemscpu.a. A configure command line option will build a multilib RTEMS as<br>
>> +shown in Building a CPU Kit.<br>
>> +<br>
>> +BSP and CPU model specific portions of RTEMS (libcpu and libbsp) are<br>
>> +built into the separate library librtemsbsp.a.<br>
>> +<br>
>> +What is the difference between the workspace and heap ?<br>
>> +----------------------------------------------------------------------<br>
>> +<br>
>> +The RTEMS Workspace is used to allocate space for objects created by RTEMS<br>
>> +such as tasks, semaphores, message queues, etc.. It is primarily used during<br>
>> +system initialization although task stacks and message buffer areas are also<br>
>> +allocated from here.<br>
>> +<br>
>> +Why should we work with the RTEMS developers ?<br>
>> +---------------------------------------------------------------------------<br>
>> +<br>
>> +Our engineers understand our target environment better than anyone else, and<br>
>> +we have a tight schedule. Why should we work with the RTEMS developers, when<br>
>> +we can get the code out faster by whacking it out on our own?<br>
>> +<br>
>> +You understand your target environment better than anyone else.<br>
>> +However, the RTEMS developers understand RTEMS better than anyone<br>
>> +else; furthermore, the RTEMS developers tend to have a wide breadth<br>
>> +of experience across a large number of processors, boards, peripherals,<br>
>> +and application domains. It has been our experience that few problems<br>
>> +encountered in embedded systems development are unique to a particular<br>
>> +processor or application. The vast majority of the time an issue that<br>
>> +arises in one project has also shown up in other projects.<br>
>> +<br>
>> +The intimate knowledge of RTEMS internals as well as a wide breadth of<br>
>> +embedded systems knowledge means that there is a good chance that at<br>
>> +least one RTEMS developer has already addressed issues you are likely<br>
>> +to face when doing your port, BSP, or application. The developers can<br>
>> +help guide you towards a workable long term solution, possibly saving<br>
>> +you significant time in your development cycle.<br>
>> +<br>
>> +If getting the sources into the official RTEMS distributions is one of<br>
>> +your goals, then engaging other RTEMS developers early will also likely<br>
>> +shorten your development time. By interacting as early as possible you<br>
>> +are more likely to write code which can be easily accepted into the official<br>
>> +sources when you are finished. If you wait until you think you are done<br>
>> +to begin interacting with the RTEMS team, you might find that you did<br>
>> +some things wrong and you may have to rewrite parts of your RTEMS port,<br>
>> +which is a waste of your valuable time.<br>
>> +<br>
>> +Why should we integrate our port into the official RTEMS sources?<br>
>> +------------------------------------------------------------------<br>
>> +<br>
>> +Why should we care if our port is integrated into the official RTEMS sources?<br>
>> +We can distribute it ourselves to whoever is interested.<br>
>> +<br>
>> +Yes, the RTEMS licenses allows you to do that. But by doing so, you end up<br>
>> +having to maintain that code yourself; this can be a significant<br>
>> +effort over time as the RTEMS sources change rapidly.<br>
>> +<br>
>> +You also lose the advantage of wider exposure by including your port<br>
>> +in the official RTEMS sources maintained by the RTEMS Project.<br>
>> +The wider exposure in the RTEMS developer and tester community will<br>
>> +help keep your work up to date with the current sources. You may even<br>
>> +find that volunteers will run the ever-growing test suite on your port<br>
>> +and fix problems during the development cycle -- sometimes without your<br>
>> +intervention.<br>
>> +<br>
>> +It has been our experience that integrated ports tend to ultimately<br>
>> +be of better quality and stay up to date from release to release.<br>
>> +<br>
>> +Aspects of my target environment that my application exploits are still under NDA<br>
>> +---------------------------------------------------------------------------------<br>
>> +<br>
>> +Nevertheless, if the target hardware is built of any commercial parts<br>
>> +that are generally available including, but not limited to, the CPU<br>
>> +or peripherals, then that portion of your work is still of general use.<br>
>> +Similarly, if you have written software that adheres to existing API or<br>
>> +interface standards, then that portion is also of general use.<br>
>> +Our experience is that most embedded applications do utilize a custom<br>
>> +mix of hardware and application, but they are built upon layers of hardware<br>
>> +and software components that are in no way unique to the project.<br>
>> +<br>
>> +If you are porting to an unreleased CPU family or model, then just<br>
>> +announcing it is important because other RTEMS users may be planning<br>
>> +to use it and some of them may already be trying to port RTEMS on<br>
>> +their own. Your customers might be happier to know that your port<br>
>> +will eventually be available. Also, there is no requirement that RTEMS<br>
>> +include all features or ports at any particular time, so you are encouraged<br>
>> +to submit discrete pieces of functionality in stages.<br>
>> +<br>
>> +Assume that your processor has some new functionality or peripherals.<br>
>> +However that functionality is still covered by NDA, but the basic core<br>
>> +architecture is not. It is still to your advantage to go ahead and work<br>
>> +with the developers early to provide a "base port" for the CPU family.<br>
>> +That base port would only use the publicly available specifications<br>
>> +until such time as the NDA is lifted. Once the NDA is lifted you can<br>
>> +work with the developers to provide the code necessary to take<br>
>> +advantage of the new functionality.<br>
>> +<br>
>> +What is the difference between autoconf and waf build system ?<br>
>> +--------------------------------------------------------------<br>
>> +<br>
>> +Waf is a build automation tool written in Python which is designed to assist<br>
>> +in the automatic compilation and installation of computer software.<br>
>> +:ref:`Converting from Autoconf/Automake to waf build system<br>
>> +<Migration_from_AutoconfAutomake>`<br>
>> diff --git a/user/start/index.rst b/user/start/index.rst<br>
>> index 17c34e1..e178209 100644<br>
>> --- a/user/start/index.rst<br>
>> +++ b/user/start/index.rst<br>
>> @@ -23,3 +23,4 @@ applications on top of RTEMS.<br>
>>      app<br>
>>      rsb-packages<br>
>>      gsoc<br>
>> +    faq<br>
>> diff --git a/user/support/contrib.rst b/user/support/contrib.rst<br>
>> index c42d41b..758f0f6 100644<br>
>> --- a/user/support/contrib.rst<br>
>> +++ b/user/support/contrib.rst<br>
>> @@ -168,98 +168,4 @@ time, or have proven very hard to integrate. So, what we are asking<br>
>>  is that, to the maximum extent possible, you communicate with us<br>
>>  as early on and as much as possible.<br>
>><br>
>> -Common Questions and Answers<br>
>> -============================<br>
>> -<br>
>> -Here are some questions RTEMS porters may have with our answers to<br>
>> -them. While the focus here is on new ports and BSPs, we believe that<br>
>> -the issues are similar for other RTEMS development efforts including<br>
>> -student efforts to implement new algorithmic optimizations.<br>
>> -<br>
>> -    Our engineers understand our target environment better than anyone else, and<br>
>> -    we have a tight schedule. Why should we work with the RTEMS developers, when<br>
>> -    we can get the code out faster by whacking it out on our own?<br>
>> -<br>
>> -You understand your target environment better than anyone else.<br>
>> -However, the RTEMS developers understand RTEMS better than anyone<br>
>> -else; furthermore, the RTEMS developers tend to have a wide breadth<br>
>> -of experience across a large number of processors, boards, peripherals,<br>
>> -and application domains. It has been our experience that few problems<br>
>> -encountered in embedded systems development are unique to a particular<br>
>> -processor or application. The vast majority of the time an issue that<br>
>> -arises in one project has also shown up in other projects.<br>
>> -<br>
>> -The intimate knowledge of RTEMS internals as well as a wide breadth of<br>
>> -embedded systems knowledge means that there is a good chance that at<br>
>> -least one RTEMS developer has already addressed issues you are likely<br>
>> -to face when doing your port, BSP, or application. The developers can<br>
>> -help guide you towards a workable long term solution, possibly saving<br>
>> -you significant time in your development cycle.<br>
>> -<br>
>> -If getting the sources into the official RTEMS distributions is one of<br>
>> -your goals, then engaging other RTEMS developers early will also likely<br>
>> -shorten your development time. By interacting as early as possible you<br>
>> -are more likely to write code which can be easily accepted into the official<br>
>> -sources when you are finished. If you wait until you think you are done<br>
>> -to begin interacting with the RTEMS team, you might find that you did<br>
>> -some things wrong and you may have to rewrite parts of your RTEMS port,<br>
>> -which is a waste of your valuable time.<br>
>> -<br>
>> -    Why should we care if our port is integrated into the official RTEMS<br>
>> -    sources? We can distribute it ourselves to whoever is interested.<br>
>> -<br>
>> -Yes, the RTEMS licenses allows you to do that. But by doing so, you end up<br>
>> -having to maintain that code yourself; this can be a significant<br>
>> -effort over time as the RTEMS sources change rapidly.<br>
>> -<br>
>> -You also lose the advantage of wider exposure by including your port<br>
>> -in the official RTEMS sources maintained by the RTEMS Project.<br>
>> -The wider exposure in the RTEMS developer and tester community will<br>
>> -help keep your work up to date with the current sources. You may even<br>
>> -find that volunteers will run the ever-growing test suite on your port<br>
>> -and fix problems during the development cycle -- sometimes without your<br>
>> -intervention.<br>
>> -<br>
>> -It has been our experience that integrated ports tend to ultimately<br>
>> -be of better quality and stay up to date from release to release.<br>
>> -<br>
>> -    Why should we communicate up front? We are happy to let the RTEMS developers<br>
>> -    integrate our stuff later.<br>
>> -<br>
>> -See above. It will save work for you over both the short and the<br>
>> -long term, and it is the right thing to do.<br>
>> -<br>
>> -    Aspects of my target environment that my application exploits are still<br>
>> -    under NDA.<br>
>> -<br>
>> -Nevertheless, if the target hardware is built of any commercial parts<br>
>> -that are generally available including, but not limited to, the CPU<br>
>> -or peripherals, then that portion of your work is still of general use.<br>
>> -Similarly, if you have written software that adheres to existing API or<br>
>> -interface standards, then that portion is also of general use.<br>
>> -Our experience is that most embedded applications do utilize a custom<br>
>> -mix of hardware and application, but they are built upon layers of hardware<br>
>> -and software components that are in no way unique to the project.<br>
>> -<br>
>> -If you are porting to an unreleased CPU family or model, then just<br>
>> -announcing it is important because other RTEMS users may be planning<br>
>> -to use it and some of them may already be trying to port RTEMS on<br>
>> -their own. Your customers might be happier to know that your port<br>
>> -will eventually be available. Also, there is no requirement that RTEMS<br>
>> -include all features or ports at any particular time, so you are encouraged<br>
>> -to submit discrete pieces of functionality in stages.<br>
>> -<br>
>> -Assume that your processor has some new functionality or peripherals.<br>
>> -However that functionality is still covered by NDA, but the basic core<br>
>> -architecture is not. It is still to your advantage to go ahead and work<br>
>> -with the developers early to provide a "base port" for the CPU family.<br>
>> -That base port would only use the publicly available specifications<br>
>> -until such time as the NDA is lifted. Once the NDA is lifted you can<br>
>> -work with the developers to provide the code necessary to take<br>
>> -advantage of the new functionality.<br>
>> -<br>
>> -Ultimately, cooperating with the free software community as early as<br>
>> -possible helps you by decreasing your development cycle, decreasing<br>
>> -your long term maintenance costs and may help raise interest in your<br>
>> -processor by having a free compiler implementation available to<br>
>> -anyone who wants to take a look.<br>
>> +<br>
> don't add extra spaces randomly<br>
> <br>
>> diff --git a/user/support/support-project.rst b/user/support/support-project.rst<br>
>> index b782029..73d5851 100644<br>
>> --- a/user/support/support-project.rst<br>
>> +++ b/user/support/support-project.rst<br>
>> @@ -6,6 +6,8 @@<br>
>><br>
>>  .. index:: support; RTEMS Project<br>
>><br>
>> +.. _RTEMS_Project_Support:<br>
>> +<br>
>>  RTEMS Project Support<br>
>>  *********************<br>
>><br>
>> --<br>
>> 2.25.1<br>
>><br>
>> _______________________________________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org" rel="noreferrer noreferrer" target="_blank">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" rel="noreferrer noreferrer" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
</blockquote></div>