--- user/start/faq.rst | 87 ++++++++++++++++++++++++++++++++++++ user/support/contrib.rst | 95 ---------------------------------------- 2 files changed, 87 insertions(+), 95 deletions(-)
diff --git a/user/start/faq.rst b/user/start/faq.rst index da11ca4..4558bce 100644 --- a/user/start/faq.rst +++ b/user/start/faq.rst @@ -246,6 +246,93 @@ 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 ? ---------------------------------------------- diff --git a/user/support/contrib.rst b/user/support/contrib.rst index c42d41b..d76fbbc 100644 --- a/user/support/contrib.rst +++ b/user/support/contrib.rst @@ -168,98 +168,3 @@ 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. -- 2.25.1 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
