Gsoc2012 project

[Joel Sherrill]

On 03/14/2012 09:37 PM, Gedare Bloom wrote:
> On Wed, Mar 14, 2012 at 10:49 AM, yangwei weiyang<wei.a.yang at gmail.com>  wrote:
>> Hi all:
>>
>>     Now the Gsoc2012 is getting more and more close. So in order to
>> select most suitable project for me
>> and rtems community from my interested projects, there are some
>> questions needed to be answered：
>> 1. In the open project page, Clang/LLVM support for RTEMS is one of my
>> interested projects. And in the
>> past days throught my investigation i have made Clang build the newlib
>> and RTEMS source code (for i386 BSP)
>> successfully. The build instruction and related information have be
>> updated on the wiki. But only this small
>> step is not enough to constitute a good proposal. So if you think this
>> is really a good project for RTEMS, could
>> you list what features you want with the Clang/LLVM support for RTEMS,
>> which contains enough tasks for
>> a summer of GSOC project.
> Ideally clang/llvm should compile all (feasible) rtems targets. This
> project would involve picking a target architecture and:
> * identifying/removing/circumventing gcc-isms
> * getting clang/llvm to compile rtems
> * running test suites
> * identifying bugs
> * filing bug reports to appropriate people (clang/llvm, rtems, or others)
> * documenting how to use clang with rtems
> * developing procedures to repeat the task for other target architectures
>
> There may be new code / code fixes required in rtems, libc (newlib),
> or even clang in order to get rtems to compile properly for any given
> target.
>
GCC-isms includes not only code that is not C99 compatible
but use of command line arguments that are specific to gcc.

clang/llvm supports a variety of architectures but the last
I checked it did not support as many architectures as gcc
nor as many CPU model variations as gcc does. For example,
it supports SPARC but not V7 only V8 and above. All RTEMS
SPARC BSPs are V7.  This one is probably fixable because it
is only an instruction or two to avoid. But for others, you may
find it is beyond a GSOC project to fix so it can only be documented.
>> 2. RTEMS Toolkits --- ApplicationConfigurationGUI is another
>> interested project for me. In the description there
>> are some protential ways to approach this project. As it says the more
>> better possibility is to write a GUI program
>> in Python and read a XML parse which read the XML format file
>> describing the RTEMS configuration parameters,
>> and then generate a header file used for RTEMS sourece code. I also
>> think this is relatively a good implement,
>> because Python has rich UI libarys like PyQt which is also
>> cross-platform and it support XML parse very well. About
>> this project what advice do you have for me?
> This project would focus on usability and capturing the richness of
> configurations for RTEMS. The tool should be extensible, as the
> configuration options tend to grow between releases of RTEMS. Note
> that right now there is no "XML format file" that describes RTEMS
> configurations---there is no standard format in fact. So part of this
> project should define a standard format or at least store
> configurations in a format that is maintainable and easy to translate
> to an application header file.
>
> I would also say that a CLI is equally important to a GUI, and that a
> Configuration project should consider how to support command-line
> usage.
>
Just to be clear we are talking about the configuration options
that an application uses to tune RTEMS for its use. These generally
start with CONFIGURE_ and are processed by confdefs.h.
>> 3. About the second project i found there was a student proposed a
>> proposal in the past but he was not accepted.
>> So i want to know whether the project about the third party package or
>> not closely related to embeded development
>> with RTEMS like development environment oiented has low priority to be accepted?
>>
> I do not know nor would I say why a past student's project did not get
> accepted. That said, the strength of the student/proposal tends to
> weigh more heavily than the priority of the project. I encourage you
> to choose a project that you feel comfortable with and have some
> passion for, because that will lead to a stronger proposal and greater
> chance for success.
Having been org admin all of the years, I can tell you that we
generally get 2-3 times more applications than we get funded
slots.  Students are selected based on a lot of factors but here
are some off the top of my head.

+ likelihood to succeed (feasibility and student's ability)
+ need for project by RTEMS
+ mentor available
+ perceived community involvement

We want students to succeed producing something we will
merge and they become part of the community long-term.

Gedare was my student two years ago and a mentor last year.
Pick something that is interesting to you first and that you
can succeed on.  I think that's the most important thing.
We want you to have fun and want to work in the community
long term.

I admit we have projects on our wish list that are not GSOC
appropriate.  Some are too large and some are just an idea
that doesn't have enough details to implement yet.  If you
end up interested in one of those, you will get discouraged
unless you can articulate the missing details. :)


>
> -Gedare
>> --
>> Wei Yang
>> Best Regards
>>
>> wei.a.yang at gmail.com
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985