want to contribute to project

Wed Mar 14 21:49:45 UTC 2018

The covoar fixes made it in but all the python stuff never made it in
because of outstanding issues in the open project page, so to see it
working, it'll have to be from the old github until the terms tester stuff
gets merged.

On Wed, 14 Mar 2018, 21:33 Joel Sherrill, <joel at rtems.org> wrote:

>
>
> On Wed, Mar 14, 2018 at 4:13 PM, Cillian O'Donnell <cpodonnell8 at gmail.com>
> wrote:
>
>>
>>
>> On 14 March 2018 at 19:51, Cillian O'Donnell <cpodonnell8 at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 14 March 2018 at 18:26, Vijay Kumar Banerjee <
>>> vijaykumar9597 at gmail.com> wrote:
>>>
>>>> I'm still getting the Covoar not found error
>>>> I'm not able to understand what am I missing, if it needs a fix, please
>>>> help me understand the code.
>>>>
>>>
>>> Have a look where all the rsb tools were built. Does covoar appear in
>>> there?
>>>
>>> The directory is something like:
>>>
>>> cd  ~/development/rtems/4.12/bin
>>>
>>
>> Sorry, nevermind that, just remenbered I had  put covoar there for
>> something else.
>>
>> You mentioned before that waf built covoar properly and it appeared in:
>>
>> "covoar is in /rtems-tools/build/covoar"
>>
>> is it this or is it rtems-tools/build/tester/covoar
>>
>> and you're definitely using the coverage-merge branch of my github
>>
>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>>
>
> It shouldn't matter much but I think we merged all your changes. If not,
> we want to
> fix that. Hopefully he can use the main rtems-tools.
>
> --joel
>
>
>>
>>>> Thanks
>>>>
>>>> On 9 March 2018 at 22:20, Vijay Kumar Banerjee <
>>>> vijaykumar9597 at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> 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/4925375616385024/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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/20180314/e4b52c31/attachment-0002.html>