want to contribute to project
Vijay Kumar Banerjee
vijaykumar9597 at gmail.com
Fri Mar 9 16:50:07 UTC 2018
On 9 Mar 2018 10:15 p.m., "Vijay Kumar Banerjee" <vijaykumar9597 at gmail.com>
wrote:
On 9 Mar 2018 3:34 a.m., "Joel Sherrill" <joel.sherrill at gmail.com> wrote:
On Sun, Mar 4, 2018 at 4:52 AM, Cillian O'Donnell <cpodonnell8 at gmail.com>
wrote:
>
>
> On 3 March 2018 at 22:18, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
> wrote:
>
>> Hello sir,
>>
>> I need some guidance to proceed to apply for #2920 as my GSoC project.
>>
>> I wanted to know the following points :
>>
>> 1. What are the prerequisites (do I have to produce something ? like the
>> hello world )
>>
>
> Other than the hello world, there's no official prerequisites. Usually the
> next thing is to fix a small bug, have a look at the tickets here:
>
> https://devel.rtems.org/query
>
>
>> 2. reference materials (like specific doc), to familiarise with the
>> rtems-tester and rsb .
>>
>
> Relevant to you would be RTEMS Tester section of the main user manual. The
> rest of the manual should be useful for setting up rtems in general.
>
> https://docs.rtems.org/branches/master/user/tools/tester.html
>
Running this and submitting some results for a BSP on a simulator would be
a good step.
This project requires doing that a lot. You can do one BSP that runs on a
gdb based simulator
and another on a qemu based simulator.
I'll surely do that . currently I'm trying to run cillian's project ,
facing some issues with the test.py , which I'll try to fix , probably it's
related to the path . I'll be at the other part of the country for a few
days (4 days ), after that I'll try to submit results for a BSP on a
simulator
There is a project based on qemu that includes coverage trace ability.
>
> The links to the previous projects which you already found and the other
> links I've mentioned.
>
>
>> 3. how to properly plan the project into phase wise tasks and weekly
>> sub-tasks.
>>
>
> Essentially it would be:
> 1. Get coverage analysis running again (converting the config files to
> .ini and a couple of fixes to some of the parsing in the sections that
> haven't been integrated, might be all that it takes).
> 2. Then get the coverage tools integrated with RTEMS Tester. Which is fix
> the outstanding issues that are mentioned in:
> https://devel.rtems.org/ticket/2920
> Chris Johns might have things to add to this, ultimately the integration
> to RTEMS Tester will be up to him.
>
I would add finishing getting the Couverture qemu into the RSB.
Okay sir.
Once the setup is running, there are a couple of meaty projects.
Chris and I have talked about reworking the report generation in covoar.
Currently, the C++ code writes HTML and txt files. It would be nice to
have covoar generate something which is subsequently processed
with a report generator. We don't have a complete solution in mind but
writing Sphinx like the RTEMS documentation is an option. One challenge
is that the current HTML output has filtering capability and that wouldn't
be possible (I think) using Sphinx.
The other desirable capability is to ensure the gcov output is correct and
can be processed by the GNU gcov tool to produce reports with the same
results as covoar. I think Cillian got a start on this but only as far as
noting
it wasn't always the same. We have a mentor from the GCC community
to help with this.
Once the gcov output is trustworthy, we can try other tools like lcov to
see what other reports we can get.
Thank you for describing the object in detail , I'll read more about covoar
and try to understand how it generates the output and how it can be
modified .
> The order in which the problems are listed in that ticket are probably the
> order in which you would complete them, the stuff about generating the xml
> reports and gcov and all of that is probably a 2nd or 3rd phase task for
> you depending on how it goes. The plan can change as you go along, its just
> important that you make a plan to begin with.
>
> Good luck,
>
> Cillian.
>
>
>>
>> Thank you,
>> Vijay k.
>>
>>
>>
>>
>>
>> On 1 March 2018 at 15:38, Cillian O'Donnell <cpodonnell8 at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 1 March 2018 at 09:10, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com
>>> > wrote:
>>>
>>>> hello,
>>>>
>>>> while trying to figure out the starting point, I came across this
>>>> project form GSoC 2017 by C.P. O'Donell
>>>>
>>>> https://summerofcode.withgoogle.com/archive/2017/projects/49
>>>> 25375616385024/
>>>>
>>>> Is this the project that has previous works on the project I'm wanting
>>>> to take (#2920) ? If not , please help me find the right one.
>>>>
>>>
>>> Hi Vijay,
>>>
>>> Yes that's the one, let me know if you have any questions about it. When
>>> I checked last month coverage is not working with the RTEMS Tester because
>>> the configuration files for the bsps in rtems-tools/tester/rtems have been
>>> converted from .mc to .ini So the old .mc files I mention need to be
>>> converted before it will work again.
>>>
>>> This is what I wrote as the final documentation, it should help you
>>> reproduce what I had working last summer.
>>>
>>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools
>>>
>>> Try this branch in github for the starting point:
>>>
>>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>>>
>>> Good luck with the project,
>>>
>>> Cillian.
>>>
>>>
>>>>
>>>> Also, please guide me with reading references and some small tickets
>>>> related to the project .
>>>>
>>>> Thank you ,
>>>> Vijay k.
>>>>
>>>>
>>>> On 26 February 2018 at 21:54, Vijay Kumar Banerjee <
>>>> vijaykumar9597 at gmail.com> wrote:
>>>>
>>>>> Thank you for giving me a detailed introduction to the project
>>>>> objectives and mentors.
>>>>> I am interested in # 2920: "Improve Coverage analysis toolkit".
>>>>>
>>>>> Please guide me with the resources to get started with the project and
>>>>> get a deep understanding.
>>>>>
>>>>> Thank you
>>>>> Vijay
>>>>>
>>>>> On 26 February 2018 at 15:36, Joel Sherrill <joel at rtems.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 26, 2018 2:22 AM, "Christian Mauderer" <
>>>>>> christian.mauderer at embedded-brains.de> wrote:
>>>>>>
>>>>>> Am 24.02.2018 um 16:21 schrieb Vijay Kumar Banerjee:
>>>>>> > Hello,
>>>>>> >
>>>>>> > As told by Joel, I sent the screenshots of my working hello world
>>>>>> to his
>>>>>> > personal email and have also included my name in the GSoC tracking
>>>>>> page .
>>>>>> >
>>>>>> >
>>>>>> > + Make Eclipse Target Interaction work with RTEMS
>>>>>> > (https://www.eclipse.org/tcf/)
>>>>>> > + Improvements to our coverage reporting. GCOV validation and covoar
>>>>>> > reporting improvements
>>>>>> > + wifi integration improvements
>>>>>> > + aarch64 port
>>>>>> > + x86_64 port / non-legacy PC BSP
>>>>>> > - This project is large so we would need to work with whoever
>>>>>> wants
>>>>>> > to tackle it
>>>>>> > to find the best subset for GSoC.
>>>>>> >
>>>>>> > Based on this list I went through the OpenProjects page
>>>>>> > and came across the following Tickets .,
>>>>>> > #2920 ,#3222,#2927 and the link to eclipse tcf .
>>>>>> >
>>>>>> >
>>>>>> > out of them , I find these interesting
>>>>>> > 1. "Improve coverage Analysis Toolset " (#2920);
>>>>>>
>>>>>>
>>>>>> This area is mine. The ticket mat or may not be a great description
>>>>>> of the goals. There are probably three things that need to be done.
>>>>>>
>>>>>> + Integrate ran recipes for Couverture variant of qemu. This might be
>>>>>> a very small task. Last year's student just didn't get this integrated and
>>>>>> was waiting for some patches to be merged on their side.
>>>>>>
>>>>>> + Verify the gcov output from covoar is correct and the gcov (and
>>>>>> similar tools) matches the coverage reports it generates. We have someone
>>>>>> from the GCC community to help mentor here.
>>>>>>
>>>>>> + Covoar generates HTML and text output directly. There is a desire
>>>>>> for it to generate something equally useful that is processed by existing
>>>>>> tools to generate reports. One possible option for this output could be
>>>>>> Sphinx like our regular documentation. Or it could be a data-centric format
>>>>>> processed by other tools. The current HTML allows filtering and sorting so
>>>>>> not losing information and ease of use is important. This probably will end
>>>>>> up simplifying C++ and adding Python.
>>>>>>
>>>>>> > 2. "libbsd:WiFi support needs rc.conf integration " (#3222)
>>>>>>
>>>>>>
>>>>>> Christian's project to mentor.
>>>>>>
>>>>>> > also I came across # 3302 :" Build system conversion of BSP
>>>>>> Config(.cfg)
>>>>>> > files to pkg-config(.pc) files"
>>>>>> > (I have some knowledge of Python, but not proficient in it, I can
>>>>>> learn
>>>>>> > it better if it's required )
>>>>>> > which I find interesting
>>>>>>
>>>>>>
>>>>>> This one is Chris Johns project to mentor. It is an important and
>>>>>> logically the next step in replacing our build system with the Python based
>>>>>> waf. If you get through this one before the summer is out, then working on
>>>>>> waf would probably make sense.
>>>>>>
>>>>>> Did I miss one?
>>>>>>
>>>>>> Hello Vijay,
>>>>>>
>>>>>> all of the projects would be good ones.
>>>>>>
>>>>>> The #2920 and #3302 are more connected to the host tools. They should
>>>>>> be
>>>>>> doable with few or no real hardware. But you should ask the two
>>>>>> potential mentors about that.
>>>>>>
>>>>>> For the #3222 you would need some board supported by the libbsd (like
>>>>>> Beagle Bone Black) and I would suggest a JTAG debugger (some OpenOCD
>>>>>> based or similar).
>>>>>>
>>>>>> >
>>>>>> > Am I following the right tickets? If not please help me find the
>>>>>> right ones.
>>>>>>
>>>>>> The tickets are the right ones.
>>>>>>
>>>>>> >
>>>>>> > Out of these , which one do you recommend me to take ?
>>>>>>
>>>>>> I would recommend to take a more detailed look at the tickets and
>>>>>> start
>>>>>> to ask some questions about it on the mailing list with CC to the
>>>>>> (potential) mentors.
>>>>>>
>>>>>> Maybe you could also try to find some small tickets related to similar
>>>>>> topics and just try to work on these. That could help you find out
>>>>>> what
>>>>>> you want to do.
>>>>>>
>>>>>> > My experience with C/C++ : I am proficient in C++11 with STL . Also
>>>>>> > proficient in C language .
>>>>>> > My experience with opensource : This is the first open source
>>>>>> project
>>>>>> > I'm taking up .
>>>>>>
>>>>>> It's no problem if it's your first Open Source project. That's the
>>>>>> point
>>>>>> of GSoC: To collect first Open Source experience.
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> Christian Mauderer
>>>>>>
>>>>>> >
>>>>>> > Thank you ,
>>>>>> > Vijay K.
>>>>>> >
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --------------------------------------------
>>>>>> embedded brains GmbH
>>>>>> Herr Christian Mauderer
>>>>>> Dornierstr. 4
>>>>>> <https://maps.google.com/?q=Dornierstr.+4+%0D+D-82178+Puchheim+%0D+Germany&entry=gmail&source=g>
>>>>>> D-82178 Puchheim
>>>>>> Germany
>>>>>> email: christian.mauderer at embedded-brains.de
>>>>>> Phone: +49-89-18 94 741 - 18
>>>>>> Fax: +49-89-18 94 741 - 08
>>>>>> PGP: Public key available on request.
>>>>>>
>>>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>>>> _______________________________________________
>>>>>> devel mailing list
>>>>>> devel at rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180309/99c2b5aa/attachment-0001.html>
More information about the devel
mailing list