Re: want to contribute to project

[Christian Mauderer]

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);
> 2.  "libbsd:WiFi support needs rc.conf integration " (#3222)
> 
> 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.

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
D-82178 Puchheim
Germany
email: christian.maude...@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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: want to contribute to project

[Joel Sherrill]

On Feb 26, 2018 2:22 AM, "Christian Mauderer" <
christian.maude...@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
D-82178 Puchheim
Germany
email: christian.maude...@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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

POSIX and return codes...

[Jakob Viketoft]

Hello!

We have a number of drivers in our BSP which all use the POSIX access methods 
to try and keep a clean interface etc. However, we also seem to stumble into a 
return error code translation issue. RTEMS seems to have a very few defined 
errno's and translate the relatively scarce amount of RTEMS error codes into an 
even sparser selection of errno codes.

We would like our drivers to be a bit communicative when encountering an error 
and the available error codes are very few due to the translation happening. Is 
there some way of forwarding a wider variety of errno numbers?

E.g. could it be possible for the translation mechanism to look if there is 
already an errno defined and then return this instead of doing the error code 
translation?

It seems like the translation I'm talking about happens in the 
rtems_deviceio_write() function in cpukit/libcsupport/src/sup_fs_deviceio.c

Are we doing it wrong or could there be some amendments to allow for bigger 
freedom here? All suggestions are appreciated.

We're currently running 4.11, but will probably move up to 5 soonish.

/Jakob
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: POSIX and return codes...

[Joel Sherrill]

On Feb 26, 2018 5:13 AM, "Jakob Viketoft" 
wrote:

Hello!

We have a number of drivers in our BSP which all use the POSIX access
methods to try and keep a clean interface etc. However, we also seem to
stumble into a return error code translation issue. RTEMS seems to have a
very few defined errno's and translate the relatively scarce amount of
RTEMS error codes into an even sparser selection of errno codes.

We would like our drivers to be a bit communicative when encountering an
error and the available error codes are very few due to the translation
happening. Is there some way of forwarding a wider variety of errno numbers?

E.g. could it be possible for the translation mechanism to look if there is
already an errno defined and then return this instead of doing the error
code translation?

It seems like the translation I'm talking about happens in the
rtems_deviceio_write() function in cpukit/libcsupport/src/sup_fs_deviceio.c

Are we doing it wrong or could there be some amendments to allow for bigger
freedom here? All suggestions are appreciated.


Completely random thought as I sit on a plane without code.

Add a field to the arguments structure for errno. See it to zero before the
call. If it is set to non-zero after the call, then the driver wanted to
return errno directly. Otherwise translate.

A middle step is to see if any of the unused RTEMS status codes make sense
to use and cover your use cases.


We're currently running 4.11, but will probably move up to 5 soonish.

/Jakob
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Contribute to project

[Abhinav Jain]

Sir,

I request you to please guide me so that I can proceed further.

Thanks and Regards
Abhinav Jain

On Feb 24, 2018 12:19 PM, "Abhinav Jain"  wrote:

> Sir,
>
> Proceeding further with the memory protection project, I have read about
> the IBM POWER architectures. I read about how memory management works
> within the POWER architecture along with Linux kernel. I specifically, read
> about POWER 8 and POWER  9 architecture and tried to understand the working
> and integration with the kernel. I read about how a 78-bit address is
> created in POWER 8 and also about the various sizes of page table support.
> Along with this, I read about syncing process between the hardware page
> table and the Linux kernel page table. I also read a little about the
> Hypervisor. In POWER 9, I read about two translation modes namely,  hash
> page table structure and radix page table structure. I found the working
> very interesting and motivating.
> I request you to please guide me, should I proceed with reading about more
> architectures and MMU support in different operating systems or should I
> change my approach?
>
> Thanks and Regards
> Abhinav Jain
>
> On Tue, Feb 20, 2018 at 8:25 PM, Abhinav Jain 
> wrote:
>
>> Sir,
>>
>> I have gone through the code and tried to trace out where the error is
>> occurring. I also read about the git status command and the problem which I
>> was able to figure out from this was with the git status command only.
>> I discussed this with Chris sir and he suggested me to make a different
>> function to check the presence of the .git file and in place of checking
>> the validity of path everywhere, this function is to be called as this
>> provides a surety that the git status is not reflecting the status of a
>> parent directory.
>>
>> Thanks and Regards
>> Abhinav Jain
>>
>> On Tue, Feb 20, 2018 at 7:22 PM, Gedare Bloom  wrote:
>>
>>> On Sun, Feb 18, 2018 at 3:19 AM, Abhinav Jain 
>>> wrote:
>>> > Sir,
>>> >
>>> > I have gone through the code concerning the issue raised. I also read
>>> about
>>> > the working of git status command and the problem that I am able to
>>> figure
>>> > out is that although the existing code is able to check whether the
>>> current
>>> > path exists or not but since it is relying on git status to check
>>> whether
>>> > the .git file is available or not, a problem is there. The git status
>>> checks
>>> > the current directory for the .git file but in case the current
>>> directory
>>> > doesn't have the .git file, it will look for it in the parent
>>> directory and
>>> > if found there it will return True, which voids the purpose.
>>> > So, I think, if a second check is given to validate whether the current
>>> > directory contains .git file or not will solve the issue.
>>> > So the code may be:
>>> > def valid(self):
>>> > if path.exists(self.path):
>>> > if path.exists(path.join(self.path, ".git")):
>>> > ec, output = self._run(['status'])
>>> > return ec == 0
>>> > return False
>>> > I request you to please guide me whether I proceeded in a right way or
>>> not.
>>> >
>>> That appears to be the code from the patch on the Trac, with Chris'
>>> comment to replace os.path.join with path.join. But, have you been
>>> able to (1) reproduce the problem, and (2) confirm this fixes it?
>>>
>>> >
>>> > Thanks and Regards
>>> > Abhinav Jain
>>> >
>>> > On Tue, Feb 13, 2018 at 10:50 AM, Abhinav Jain 
>>> > wrote:
>>> >>
>>> >> Sir,
>>> >>
>>> >> Thanks for the guidance. I will study the code available and will try
>>> to
>>> >> resolve the issue as soon as possible.
>>> >>
>>> >> Thanks and Regards
>>> >> Abhinav Jain
>>> >>
>>> >> On Tue, Feb 13, 2018 at 4:47 AM, Chris Johns 
>>> wrote:
>>> >>>
>>> >>> On 13/02/2018 06:05, Gedare Bloom wrote:
>>> >>> > Abhinav,
>>> >>> >
>>> >>> > Attempt to reproduce the reported problem, try out the patch and
>>> see
>>> >>> > if it works. I see this was reported for 4.10. See if the problem
>>> also
>>> >>> > affects 4.11, master, and if the fix works for them too.
>>> >>>
>>> >>> I suspect it is common to all branches.
>>> >>>
>>> >>> >
>>> >>> > On Mon, Feb 12, 2018 at 11:55 AM, Abhinav Jain <
>>> jainab.2...@gmail.com>
>>> >>> > wrote:
>>> >>> >> Sir,
>>> >>> >>
>>> >>> >> I have gone through the projects available in the link provided
>>> by you
>>> >>> >> and I
>>> >>> >> am interested in an issue (RSB can sometimes change the wrong
>>> local
>>> >>> >> git
>>> >>> >> repository (includes a fix).) listed there.
>>> >>> >> Link: https://devel.rtems.org/ticket/2522#no1
>>> >>> >> I request you to please provide some more information regarding
>>> this
>>> >>> >> so that
>>> >>> >> I can proceed with the coding part.
>>> >>> >>
>>> >>>
>>> >>> As Gedare suggests take a look at the master and 4.11 branches and if
>>> >>> present
>>> >>> work I suggest you work on the master branch and then we can take
>>> git.py
>>> >>> and
>>> >>> back port to 4.11 and 4.10 by simply coping git.py to tho

RE: POSIX and return codes...

[Jakob Viketoft]

Hello Joel,

From: Joel Sherrill [j...@rtems.org]
Sent: Monday, February 26, 2018 12:21

> On Feb 26, 2018 5:13 AM, "Jakob Viketoft"  
> wrote:
>> E.g. could it be possible for the translation mechanism to look if there is 
>> already an errno defined and then return this instead of doing the error 
>> code translation?

>> It seems like the translation I'm talking about happens in the 
>> rtems_deviceio_write() function in cpukit/libcsupport/src/sup_fs_deviceio.c

> Completely random thought as I sit on a plane without code. 

> Add a field to the arguments structure for errno. See it to zero before the 
> call. If it is set to non-zero after the call, then the driver wanted to 
> return errno directly. Otherwise translate.

This was my thought as well, I just wanted to bounce it off the RTEMS list and 
also possibly get official support for a feature as this.

> A middle step is to see if any of the unused RTEMS status codes make sense to 
> use and cover your use cases.

This is the way we do it today. Unfortunately, so many of the different RTEMS 
codes are translated into the same errno codes which makes it very hard to have 
an intelligent error reporting/differentiation.

  /Jakob
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: POSIX and return codes...

[Joel Sherrill]

On Feb 26, 2018 8:27 AM, "Jakob Viketoft" 
wrote:

Hello Joel,

From: Joel Sherrill [j...@rtems.org]
Sent: Monday, February 26, 2018 12:21

> On Feb 26, 2018 5:13 AM, "Jakob Viketoft" 
wrote:
>> E.g. could it be possible for the translation mechanism to look if there
is already an errno defined and then return this instead of doing the error
code translation?

>> It seems like the translation I'm talking about happens in the
rtems_deviceio_write() function in cpukit/libcsupport/src/sup_fs_deviceio.c

> Completely random thought as I sit on a plane without code.

> Add a field to the arguments structure for errno. See it to zero before
the call. If it is set to non-zero after the call, then the driver wanted
to return errno directly. Otherwise translate.

This was my thought as well, I just wanted to bounce it off the RTEMS list
and also possibly get official support for a feature as this.


Now boarded on a different plane and have had another round of thinking.

What if an RTEMS status code were added like RTEMS_STATUS_IN_ERRNO and we
don't modify the arguments structure. Then a driver could return that
status to trip -1 and errno.

Just a thought. I think it would make the code cleaner but another core
developer should pipe up. I was up at 3am to catch a flight and could be
loopy. :)


> A middle step is to see if any of the unused RTEMS status codes make
sense to use and cover your use cases.

This is the way we do it today. Unfortunately, so many of the different
RTEMS codes are translated into the same errno codes which makes it very
hard to have an intelligent error reporting/differentiation.

  /Jakob
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: POSIX and return codes...

[Sebastian Huber]

Hello Jakob,

you can also register drivers with IMFS_make_generic_node(). Please note that 
this API is not yet stable. See the testsuite for examples.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: want to contribute to project

[Vijay Kumar Banerjee]

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  wrote:

>
>
> On Feb 26, 2018 2:22 AM, "Christian Mauderer" <
> christian.maude...@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
> 
> D-82178 Puchheim
> Germany
> email: christian.maude...@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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
___