<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 10, 2017 at 4:01 PM, Chris Johns <span dir="ltr"><<a href="mailto:chris@contemporary.net.au" target="_blank">chris@contemporary.net.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 10/01/2017 19:46, Denis Obrezkov wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I am a first-year phd student in Russia and I can help you to recruit me:)<br>
</blockquote>
<br></span>
Welcome and thank you for presenting these idea.<br>
<br>
I have trimmed the list to the ideas I have answered ...<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Secondly, some degree of IoT support is very desirable, because nowadays<br>
IoT<br>
lacks reliability and safety. Thus, I think, this task includes not only<br>
porting packages<br>
and implementing protocols but also architecture development and creation of<br>
documentation that describes how to properly utilize provided capabilities.<br>
Also, I think there is a huge trend towards distributed sensor networks<br>
and distributed<br>
embedded systems.<br>
</blockquote>
<br></span>
Yes it is becoming more and more important.<br>
<br>
This topic feeds into the discussion Joel and I have been having on the RSB and 3rd party packages. The idea is the RSB with 3rd party packages forms a vertical integration stack of application code. The graphics toolkit in the RSB is an example. You ask the RSB to build the toolkit and it fetches and builds a number a packages needed to make that application stack.<span class="gmail-"><br>
<br></span></blockquote><div>There should be plenty of third party packages out there which together make a nice IoT</div><div>application stack. Part of the RTEMS philosophy is to focus on what we have to do and</div><div>use great third party code for what we can. Thus the kernel is ours while the network stack</div><div>is FreeBSD or LWIP.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Lastly, I think it would be good to implement some kind of configuration<br>
tool support.<br>
As example, Linux has a very simple but also very flexible configuration<br>
tool..<br>
</blockquote>
<br></span>
This is something RTEMS needs. There are 2 parts to configuring RTEMS for an application:<br>
<br>
1. Kernel build<br>
2. Runtime configuration<br>
<br>
A kernel configuration tool will need to wait until we change from the autotconf/automake build system to waf. Part of the requirements for waf is to bring all the configuration items in RTEMS, including the BSP options, out into a formalised interface with suitable documentation. Until this is done and we have something concrete any attempts at a configuration could be wasted effort. The ability to get this information from the current build system is difficult and messy.<br>
<br>
The runtime configuration would be based around confdefs.h and it would generate an init.c or system.h or whatever. This is open but I am not sure how big or challenging a task it is on it's own.<span class="gmail-HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div>There was a gsoc project a few years ago which read the user documentation for confdefs.h and</div><div>used that to generate the menu, options, tool tips, data type, etc. Ignoring issues Chris and I</div><div>have discussed about how using the documentation to do this risks having the doc and tool</div><div>out of sync with the real code, there is a basic new issue:</div><div><br></div><div>+ the documentation is in a new format - Sphinx - so even if we used the exact same </div><div>approach, the tool reads the wrong format input. </div><div><br></div><div>That project is discussed at <a href="https://devel.rtems.org/wiki/Projects/GSoC/ApplicationConfigurationGUI">https://devel.rtems.org/wiki/Projects/GSoC/ApplicationConfigurationGUI</a></div><div>and includes links to the github.</div><div><br></div><div>Seeing if we can solve the code=doc=tool problem and updating the tool so the Sphinx docs</div><div>match the tool options would be a good project and make this concept something we could</div><div>trust.</div><div><br></div><div>Off the top of my head, I think Chris and I thought that if the confdefs.h documentation</div><div>could be generated from that file AND the tool also read that file, then it would be OK.</div><div>The risk is getting them out of sync.</div><div><br></div><div>Chris.. could we define a few requirements to address the input path to this tool?</div><div>I think the idea that the tool read its input and generated the menus and input</div><div>options solved the issue of having actual code reflect confdefs.h.</div><div><br></div><div>It would be nice to get this into production.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-HOEnZb"><font color="#888888">
Chris<br>
</font></span></blockquote></div><br></div></div>