[PATCH rtems-docs v2 1/2] Added FAQ page

Sun Apr 4 01:57:05 UTC 2021

On 4/4/21 10:55 am, Ayushman Mishra wrote:
> And sir ,

Chris is fine. I appreciate you using a formal name but in RTEMS there is no
need. You are welcome here as a member of the community just like me. :)

> if we can't use cross-link should I write a sentence like
> for eg. " (Please refer section 6.1.12. "Creating a Patch" of RTEMS
> Software Engineering manual in :r:url:`docs`) for question How do I
> make a patch? "

I think referring to the section name is best because the section number can and
will change and adding a specific section number creates an untracked dependency.

What you are attempting to do is appropriate and wanted however what we have at
the moment in our documentation framework does not support it. I would like to
tackle this and see how we could manage crosslinks in a scalable and
multi-format way but it is low on my queue of things to do.

Chris

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