want to contribute to project

Wed Mar 14 18:39:49 UTC 2018

On Wed, Mar 14, 2018 at 1:26 PM, 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.
>

covoar is now part of the rtems-tools package so you need to build and
install that.

FYI I still have your draft proposal up and it is in my queue to review.

--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/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
>>>
>>
>>
>>
>>
>
> _______________________________________________
> 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/c51fa932/attachment-0002.html>