GSOC 2017 Approaching

[Kevin Du Huanpeng]

发自我的iPhone

------------------ Original ------------------
From: Chris Johns <chrisj at rtems.org>
Date: 周三,1月 11,2017 07:15
To: Denis Obrezkov <denisobrezkov at gmail.com>, joel <joel at rtems.org>
Cc: rtems-users at rtems.org <users at rtems.org>
Subject: Re: GSOC 2017 Approaching



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.

> 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.

Chris
_______________________________________________
users mailing list
users at rtems.org
http://lists.rtems.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170111/d6975203/attachment-0002.html>