GSOC 2017 Approaching

[Joel Sherrill]

On Tue, Jan 10, 2017 at 4:01 PM, Chris Johns <chris at contemporary.net.au>
wrote:

> On 10/01/2017 19:46, Denis Obrezkov wrote:
>
>>
>> I am a first-year phd student in Russia and I can help you to recruit me:)
>>
>
> Welcome and thank you for presenting these idea.
>
> I have trimmed the list to the ideas I have answered ...
>
>
>> Secondly, some degree of IoT support is very desirable, because nowadays
>> IoT
>> lacks reliability and safety. Thus, I think, this task includes not only
>> porting packages
>> and implementing protocols but also architecture development and creation
>> of
>> documentation that describes how to properly utilize provided
>> capabilities.
>> Also, I think there is a huge trend towards distributed sensor networks
>> and distributed
>> embedded systems.
>>
>
> Yes it is becoming more and more important.
>
> 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.
>
> There should be plenty of third party packages out there which together
make a nice IoT
application stack. Part of the RTEMS philosophy is to focus on what we have
to do and
use great third party code for what we can. Thus the kernel is ours while
the network stack
is FreeBSD or LWIP.


> Lastly, I think it would be good to implement some kind of configuration
>> tool support.
>> As example, Linux has a very simple but also very flexible configuration
>> tool..
>>
>
> This is something RTEMS needs. There are 2 parts to configuring RTEMS for
> an application:
>
> 1. Kernel build
> 2. Runtime configuration
>
> 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.
>
> 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.
>
> There was a gsoc project a few years ago which read the user documentation
for confdefs.h and
used that to generate the menu, options, tool tips, data type, etc.
Ignoring issues Chris and I
have discussed about how using the documentation to do this risks having
the doc and tool
out of sync with the real code, there is a basic new issue:

+ the documentation is in a new format - Sphinx - so even if we used the
exact same
approach, the tool reads the wrong format input.

That project is discussed at
https://devel.rtems.org/wiki/Projects/GSoC/ApplicationConfigurationGUI
and includes links to the github.

Seeing if we can solve the code=doc=tool problem and updating the tool so
the Sphinx docs
match the tool options would be a good project and make this concept
something we could
trust.

Off the top of my head, I think Chris and I thought that if the confdefs.h
documentation
could be generated from that file AND the tool also read that file, then it
would be OK.
The risk is getting them out of sync.

Chris.. could we define a few requirements to address the input path to
this tool?
I think the idea that the tool read its input and generated the menus and
input
options solved the issue of having actual code reflect confdefs.h.

It would be nice to get this into production.


> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170110/7a70fe30/attachment.html>