GSOC'18 contribution plan

[Gedare Bloom]

On Tue, Mar 13, 2018 at 10:07 AM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Tue, Mar 13, 2018 at 8:46 AM, Vidushi Vashishth <reachvidu at gmail.com>
> wrote:
>>
>> Hello!
>>
>> I am Vidushi Vashishth from Netaji Subhas Institute of Technology, Delhi
>> and I intend to participate in the selection procedure for GSOC'18. I have
>> already submitted the Hello world patch. The past couple of days I have been
>> going through the open projects and I am interested in the ones below:
>
>
> Awesome! Make sure you are on the list here.
>>
>>
>> 1) Run time tracing
>> For this project I have been reading about the Common Trace Format
>> Integration, Trace Buffering, RTEMS trace linker's working which utilises
>> INI configuration files. I have been following the ticket #3028. I am
>> currently working on the tasks present on the ticket's description. It would
>> be helpful if the community could point out to any other relevant issues
>> which I could work on to get a better idea about this project. I would get
>> back when I find one myself. As suggested on the mailing list, I would also
>> like to investigate the TCF project to see if a combination of both of these
>> can be undertaken in one summer. Let me know if this is too optimistic.
>
>
> As I mentioned on another thread this morning, CTF and TCF are IMO very
> important things
> for RTEMS to support. Sebastian was commenting how the tracing would help
> him.
> If I had to assign a priority to the two, I guess I would put CTF first
> because it fills a gap.
> TCF is also important but we do have debugging now but TCF might offer some
> unique
> capability we don't have.
>
>>
>>
>> 2) Rump Kernels
>> The project's description was a little open ended but garnered my
>> interest. It would require a little more research from my end to come up
>> with ideas myself. I would do that if time permits.
>
>
> Given the current status of libbsd, I am not sure what the goal of it would
> be. I think
> originally it was proposed as an alternative way to get many BSD
> capabilities onto
> RTEMS.
>
> Can someone comment?
>

Rump kernels may still have utility for adopting portable subsystems
from NetBSD code base without a major import hassle. It also could be
complementary to libbsd perhaps. Hesham did some initial research in
this direction before being distracted by other pursuits, so he might
have some more insight. He wrote a blog post about it before...

Gedare

>>
>>
>> I intend to write my proposal in a week's time.
>>
>> References:
>> https://devel.rtems.org/ticket/3028
>> https://devel.rtems.org/wiki/Developer/Projects/Open/RumpKernels
>>
>> Best,
>> Vidushi
>>
>