GSOC 2017 Approaching
Kevin Du Huanpeng
norep1y at 21cn.com
Tue Jan 10 23:06:51 UTC 2017
------------------ 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
> 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
> 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
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.
users mailing list
users at rtems.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users