Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

Hello Niteesh,

On 30/08/2020 08:58, Niteesh G. S. wrote:
> Hello,
> 
> I have updated the blog to contain the links to the commits
> instead of the branches. Please have a look again.
> https://gs-niteesh.github.io/finalreport/

From my point of view, it looks good now. You missed the commit with the
refactored i2c driver:

https://github.com/gs-niteesh/rtems/commit/be9bd605c40cf7cbcf3f527054fdbab2af39f52a

But if you don't have time left it's not a problem if it isn't there.

The Submission guidelines tell that "It must be easy to identify the
work you have done." From my point of view that was already quite clear
because the commits are all on top of the final branch. But Gedare is of
course right: Linking every commit is a bit more clear.

> 
> And sorry to disturb on the weekend,  but we have only about
> a day left before the submission deadline, so I request
> everyone to please take a look and let me know if you would
> like to change anything.

No problem for disturbing in this case. Don't miss your deadline. It's
better to submit something that is not perfect than not submitting
anything. We would have no possibility to fix a missed submission.

Best regards

Christian

> 
> Thanks,
> Niteesh.
> 
> On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom  > wrote:
> 
> On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> >
> >
> >
> > On 29/08/2020 15:04, Niteesh G. S. wrote:
> > > Hello,
> > > On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer
> mailto:o...@c-mauderer.de>
> > > >> wrote:
> > >
> > >     Hello Niteesh
> > >
> > >     On 29/08/2020 11:22, Niteesh G. S. wrote:
> > >     > On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer
> > >     mailto:o...@c-mauderer.de>
> >
> > >     > 
>  > >     >
> > >     >     On 29/08/2020 05:57, Niteesh G. S. wrote:
> > >     >     > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom
> > >     mailto:ged...@rtems.org>
> >
> > >     >     
> >>
> > >     >     > 
> >
> > >     
>  wrote:
> > >     >     >
> > >     >     >     Are "Links to commits" 1-4 all the code you (are
> > >     claiming you)
> > >     >     wrote?
> > >     >     >     I just want to make sure. It looks fine to me.
> > >     >     >
> > >     >     > Yes, all the code in the commits is written by me.
> > >     >
> > >     >     I think maybe "Links to branches" would be a better
> title. It
> > >     is not a
> > >     >     single commit each but a few commits. Alternative
> would be to
> > >     add links
> > >     >     to each commit.
> > >     >
> > >     >
> > >     > I have changed the title to "Links to branches". Should I
> also add
> > >     links
> > >     > to the commits that were made in each phase at the end of the
> > >     summary of
> > >     > each phase?
> > >     >
> > >
> > >     If you want, you can do that.
> > >
> > >
> > > I did try that but it didn't work out well, especially with the
> OFW commit.
> > > Since I don't have the old commit I either had to leave that
> commit out
> > > in the first phase or I had to post the newer commit in the
> first phase
> > > itself which actually should in the last phase. So I decided to
> avoid adding
> > > the commits and just leave it out with the branches.
> >
> > That's OK too. Like I said: Main target was that it's clear that you
> > don't have four commits but a bit more.
> >
> 
> Oh, I'm sorry I didn't notice this. We actually do want it to be
> distinctly your commits. Since you have commits that are older than
> this GSoC in rtems, you can't use the author filtering feature
> 
> (https://github.com/gs-niteesh/rtems/commits/beagle-rtems6-pinmux-18-aug?author=gs-niteesh)
> so you'll probably need to generate the links to each commit.
> 
> This is something required by Google.
> 
> > >
> > >
> > >     The main point of that change was to highlight that it's not
> 4 commits
> > >     but a bit more.
> > >
> > >     >
> > >     >
> > >     >
> > >     >
> > >     >     It has been quite a bit of back and forth during this GSoC
> > >     project so I

Re: GSoC 2020 - Final project report

[Utkarsh Rai]

I have updated my post with the help of all of your suggestions. As @Niteesh
G. S.   said, sorry to disturb you on a weekend but
please take a look.

On Sat, Aug 29, 2020 at 6:03 PM Utkarsh Rai  wrote:

>
>
> On Sat, Aug 29, 2020 at 3:59 PM Hesham Almatary <
> hesham.almat...@cl.cam.ac.uk> wrote:
>
>> Hello Utkarsh,
>>
>> Thanks for the blog post. Are there any instructions on how can
>> someone (maybe a future GSoC student or someone else interested) get
>> your code tested (with test demos) and on which platform? A HOWTO
>> guide/blogpost will be great.
>>
>
> Currently no, as there are a couple more tests that I want to get
> reviewed. I will update my post according to your suggestions by today
>
>
>>
>> On Sat, 29 Aug 2020 at 00:51, Utkarsh Rai 
>> wrote:
>> >
>> >
>> >
>> > On Sat, Aug 29, 2020 at 4:18 AM Gedare Bloom  wrote:
>> >>
>> >> Similarly, I would like to have a consolidated set of links to "your
>> >> code" instead of having them woven in with the narrative and links to
>> >> blogs etc.
>> >>
>> >
>> > Ok, I will do that.
>> >
>> >>
>> >> On Thu, Aug 27, 2020 at 6:33 PM Utkarsh Rai 
>> wrote:
>> >> >
>> >> > Hello,
>> >> > I have prepared a tentative final report for my project. You can
>> view it here. Note there are few changes to be made in the report based on
>> my progress this week as I am working on static initialization of PMP and
>> the v5 patch for thread-stack isolation and sharing.
>> >> > ___
>> >> > 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
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Niteesh G. S.]

Hello,

On Sun, Aug 30, 2020 at 4:12 PM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> On 30/08/2020 08:58, Niteesh G. S. wrote:
> > Hello,
> >
> > I have updated the blog to contain the links to the commits
> > instead of the branches. Please have a look again.
> > https://gs-niteesh.github.io/finalreport/
>
> From my point of view, it looks good now. You missed the commit with the
> refactored i2c driver:
>
Sorry about that. I fixed this.

>
> https://github.com/gs-niteesh/rtems/commit/be9bd605c40cf7cbcf3f527054fdbab2af39f52a
>
> But if you don't have time left it's not a problem if it isn't there.
>
> The Submission guidelines tell that "It must be easy to identify the
> work you have done." From my point of view that was already quite clear
> because the commits are all on top of the final branch. But Gedare is of
> course right: Linking every commit is a bit more clear.
>
>
> > And sorry to disturb on the weekend,  but we have only about
> > a day left before the submission deadline, so I request
> > everyone to please take a look and let me know if you would
> > like to change anything.
>
> No problem for disturbing in this case. Don't miss your deadline. It's
> better to submit something that is not perfect than not submitting
> anything. We would have no possibility to fix a missed submission.
>

I have to submit it before tomorrow 11:30 PM IST. I'll leave it tonight
for others to comment and will fill it tomorrow morning.

Thanks,
Niteesh.


Best regards
>
> Christian
>
> >
> > Thanks,
> > Niteesh.
> >
> > On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom  > > wrote:
> >
> > On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer
> > mailto:o...@c-mauderer.de>> wrote:
> > >
> > >
> > >
> > > On 29/08/2020 15:04, Niteesh G. S. wrote:
> > > > Hello,
> > > > On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer
> > mailto:o...@c-mauderer.de>
> > > > >> wrote:
> > > >
> > > > Hello Niteesh
> > > >
> > > > On 29/08/2020 11:22, Niteesh G. S. wrote:
> > > > > On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer
> > > > mailto:o...@c-mauderer.de>
> > >
> > > > > 
> >  > > > >
> > > > > On 29/08/2020 05:57, Niteesh G. S. wrote:
> > > > > > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom
> > > > mailto:ged...@rtems.org>
> > >
> > > > > 
> > >>
> > > > > > 
> > >
> > > > 
> >  wrote:
> > > > > >
> > > > > > Are "Links to commits" 1-4 all the code you (are
> > > > claiming you)
> > > > > wrote?
> > > > > > I just want to make sure. It looks fine to me.
> > > > > >
> > > > > > Yes, all the code in the commits is written by me.
> > > > >
> > > > > I think maybe "Links to branches" would be a better
> > title. It
> > > > is not a
> > > > > single commit each but a few commits. Alternative
> > would be to
> > > > add links
> > > > > to each commit.
> > > > >
> > > > >
> > > > > I have changed the title to "Links to branches". Should I
> > also add
> > > > links
> > > > > to the commits that were made in each phase at the end of
> the
> > > > summary of
> > > > > each phase?
> > > > >
> > > >
> > > > If you want, you can do that.
> > > >
> > > >
> > > > I did try that but it didn't work out well, especially with the
> > OFW commit.
> > > > Since I don't have the old commit I either had to leave that
> > commit out
> > > > in the first phase or I had to post the newer commit in the
> > first phase
> > > > itself which actually should in the last phase. So I decided to
> > avoid adding
> > > > the commits and just leave it out with the branches.
> > >
> > > That's OK too. Like I said: Main target was that it's clear that
> you
> > > don't have four commits but a bit more.
> > >
> >
> > Oh, I'm sorry I didn't notice this. We actually do want it to be
> > distinctly your commits. Since you have commits that are older than
> > this GSoC in rtems, you can't use the author filtering feature
> > (
> https://github.com/gs-niteesh/rtems/commits/beagle-rtems6

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

On 30/08/2020 14:38, Niteesh G. S. wrote:
> Hello,
> 
> On Sun, Aug 30, 2020 at 4:12 PM Christian Mauderer  > wrote:
> 
> Hello Niteesh,
> 
> On 30/08/2020 08:58, Niteesh G. S. wrote:
> > Hello,
> >
> > I have updated the blog to contain the links to the commits
> > instead of the branches. Please have a look again.
> > https://gs-niteesh.github.io/finalreport/
> 
> >From my point of view, it looks good now. You missed the commit
> with the
> refactored i2c driver:
> 
> Sorry about that. I fixed this. 
> 
> 
> https://github.com/gs-niteesh/rtems/commit/be9bd605c40cf7cbcf3f527054fdbab2af39f52a
> 
> But if you don't have time left it's not a problem if it isn't there.
> 
> The Submission guidelines tell that "It must be easy to identify the
> work you have done." From my point of view that was already quite clear
> because the commits are all on top of the final branch. But Gedare is of
> course right: Linking every commit is a bit more clear.
> 
> 
> > And sorry to disturb on the weekend,  but we have only about
> > a day left before the submission deadline, so I request
> > everyone to please take a look and let me know if you would
> > like to change anything.
> 
> No problem for disturbing in this case. Don't miss your deadline. It's
> better to submit something that is not perfect than not submitting
> anything. We would have no possibility to fix a missed submission.
> 
> 
> I have to submit it before tomorrow 11:30 PM IST. I'll leave it tonight
> for others to comment and will fill it tomorrow morning.

Be really careful to not miss a deadline. Again: We have no chance of
fixing a missed deadline.

Best regards

Christian

> 
> Thanks,
> Niteesh.
> 
> 
> Best regards
> 
> Christian
> 
> >
> > Thanks,
> > Niteesh.
> >
> > On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom  
> > >> wrote:
> >
> >     On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer
> >     mailto:o...@c-mauderer.de>
> >> wrote:
> >     >
> >     >
> >     >
> >     > On 29/08/2020 15:04, Niteesh G. S. wrote:
> >     > > Hello,
> >     > > On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer
> >     mailto:o...@c-mauderer.de>
> >
> >     > > 
>  >     > >
> >     > >     Hello Niteesh
> >     > >
> >     > >     On 29/08/2020 11:22, Niteesh G. S. wrote:
> >     > >     > On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer
> >     > >     mailto:o...@c-mauderer.de>
> >
> >     
> >>
> >     > >     > 
> >
> >     
>  wrote:
> >     > >     >
> >     > >     >     On 29/08/2020 05:57, Niteesh G. S. wrote:
> >     > >     >     > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom
> >     > >     mailto:ged...@rtems.org>
> >
> >     
> >>
> >     > >     >        >
> >     
>  >     > >     >     >    >
> >     
> >>
> >     > >     
> >
> >     
> > wrote:
> >     > >     >     >
> >     > >     >     >     Are "Links to commits" 1-4 all the code
> you (are
> >     > >     claiming you)
> >     > >     >     wrote?
> >     > >     >     >     I just want to make sure. It looks fine to me.
> >     > >     >     >
> >     > >     >     > Yes, all the code in the commits is written by me.
> >     > >     >
> >     > >     >     I think maybe "Links to branc

Re: [PATCH 7/7] rtems: Add rtems_task_build()

[Sebastian Huber]

On 22/08/2020 09:49, Chris Johns wrote:


On 21/8/20 9:51 pm, Sebastian Huber wrote:

In contrast to rtems_task_create() this function creates a task with a
user-provided task storage area.

The name is build but it creates a task? I am wondering about
rtems_task_create_static or something along this line?


A function to do a static initialization is a contradiction from my 
point of view. Static initialization means for me that you statically 
initialize a data structure and then it is ready to use (it may involve 
a static constructor).


The function builds a task from user-provided (stack, attributes, etc.) 
and system-provided (thread control block) components.





Close #3959.

Sorry, I had not read the ticket's details.


There is a similar ticket for message queues:

https://devel.rtems.org/ticket/4007



Chris


---
  cpukit/Makefile.am |   1 +
  cpukit/include/rtems/rtems/tasks.h |  65 ++
  cpukit/include/rtems/rtems/tasksimpl.h |  11 +
  cpukit/rtems/src/taskbuild.c   | 273 
  cpukit/rtems/src/taskcreate.c  | 274 +
  testsuites/sptests/sp01/init.c |  22 +-
  testsuites/sptests/sp01/sp01.doc   |   1 +
  testsuites/sptests/sp01/system.h   |   2 +-
  8 files changed, 413 insertions(+), 236 deletions(-)
  create mode 100644 cpukit/rtems/src/taskbuild.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index bc56822cf8..e382478eac 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -785,6 +785,7 @@ librtemscpu_a_SOURCES += rtems/src/statustext.c
  librtemscpu_a_SOURCES += rtems/src/statustoerrno.c
  librtemscpu_a_SOURCES += rtems/src/systemeventreceive.c
  librtemscpu_a_SOURCES += rtems/src/systemeventsend.c
+librtemscpu_a_SOURCES += rtems/src/taskbuild.c
  librtemscpu_a_SOURCES += rtems/src/taskcreate.c
  librtemscpu_a_SOURCES += rtems/src/taskdelete.c
  librtemscpu_a_SOURCES += rtems/src/taskexit.c
diff --git a/cpukit/include/rtems/rtems/tasks.h 
b/cpukit/include/rtems/rtems/tasks.h
index 12c323e60e..dff811686a 100644
--- a/cpukit/include/rtems/rtems/tasks.h
+++ b/cpukit/include/rtems/rtems/tasks.h
@@ -164,6 +164,71 @@ rtems_status_code rtems_task_create(
[...]
+  /**
+   * @brief This member defines the optional handler to free the task storage
+   *   area.
+   *
+   * It may be NULL.
+   */
+  void ( *storage_free )( void * );

Called under what context? What can this call do? For example call the standard
heap allocator.


This is a good question.  What about:

@brief This member defines the optional handler to free the task storage 
area.


It is called when the task building aborts due to a failed task create 
extension or the task is deleted. It is called from task context under 
protection of the object allocator lock. It is allowed to call free() in 
this handler.


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

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Gedare Bloom]

looks great

On Sun, Aug 30, 2020 at 6:55 AM Christian Mauderer  wrote:
>
> On 30/08/2020 14:38, Niteesh G. S. wrote:
> > Hello,
> >
> > On Sun, Aug 30, 2020 at 4:12 PM Christian Mauderer  > > wrote:
> >
> > Hello Niteesh,
> >
> > On 30/08/2020 08:58, Niteesh G. S. wrote:
> > > Hello,
> > >
> > > I have updated the blog to contain the links to the commits
> > > instead of the branches. Please have a look again.
> > > https://gs-niteesh.github.io/finalreport/
> >
> > >From my point of view, it looks good now. You missed the commit
> > with the
> > refactored i2c driver:
> >
> > Sorry about that. I fixed this.
> >
> > 
> > https://github.com/gs-niteesh/rtems/commit/be9bd605c40cf7cbcf3f527054fdbab2af39f52a
> >
> > But if you don't have time left it's not a problem if it isn't there.
> >
> > The Submission guidelines tell that "It must be easy to identify the
> > work you have done." From my point of view that was already quite clear
> > because the commits are all on top of the final branch. But Gedare is of
> > course right: Linking every commit is a bit more clear.
> >
> >
> > > And sorry to disturb on the weekend,  but we have only about
> > > a day left before the submission deadline, so I request
> > > everyone to please take a look and let me know if you would
> > > like to change anything.
> >
> > No problem for disturbing in this case. Don't miss your deadline. It's
> > better to submit something that is not perfect than not submitting
> > anything. We would have no possibility to fix a missed submission.
> >
> >
> > I have to submit it before tomorrow 11:30 PM IST. I'll leave it tonight
> > for others to comment and will fill it tomorrow morning.
>
> Be really careful to not miss a deadline. Again: We have no chance of
> fixing a missed deadline.
>
> Best regards
>
> Christian
>
> >
> > Thanks,
> > Niteesh.
> >
> >
> > Best regards
> >
> > Christian
> >
> > >
> > > Thanks,
> > > Niteesh.
> > >
> > > On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom  > 
> > > >> wrote:
> > >
> > > On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer
> > > mailto:o...@c-mauderer.de>
> > >> wrote:
> > > >
> > > >
> > > >
> > > > On 29/08/2020 15:04, Niteesh G. S. wrote:
> > > > > Hello,
> > > > > On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer
> > > mailto:o...@c-mauderer.de>
> > >
> > > > > 
> >  > > > >
> > > > > Hello Niteesh
> > > > >
> > > > > On 29/08/2020 11:22, Niteesh G. S. wrote:
> > > > > > On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer
> > > > > mailto:o...@c-mauderer.de>
> > >
> > > 
> > >>
> > > > > > 
> > >
> > > 
> >  wrote:
> > > > > >
> > > > > > On 29/08/2020 05:57, Niteesh G. S. wrote:
> > > > > > > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom
> > > > > mailto:ged...@rtems.org>
> > >
> > > 
> > >>
> > > > > >  >   > >
> > > 
> >  > > > > > >  >   > >
> > > 
> > >>
> > > > > 
> > >
> > > 
> > > wrote:
> > > > > > >
> > > > > > > Are "Links to commits" 1-4 all the code
> > you (are
> > > > > claiming you)
> >  

Re: GSoC 2020 - Final project report

[Gedare Bloom]

Looks great

On Sun, Aug 30, 2020 at 4:55 AM Utkarsh Rai  wrote:
>
> I have updated my post with the help of all of your suggestions. As @Niteesh 
> G. S.  said, sorry to disturb you on a weekend but please take a look.
>
> On Sat, Aug 29, 2020 at 6:03 PM Utkarsh Rai  wrote:
>>
>>
>>
>> On Sat, Aug 29, 2020 at 3:59 PM Hesham Almatary 
>>  wrote:
>>>
>>> Hello Utkarsh,
>>>
>>> Thanks for the blog post. Are there any instructions on how can
>>> someone (maybe a future GSoC student or someone else interested) get
>>> your code tested (with test demos) and on which platform? A HOWTO
>>> guide/blogpost will be great.
>>
>>
>> Currently no, as there are a couple more tests that I want to get reviewed. 
>> I will update my post according to your suggestions by today
>>
>>>
>>>
>>> On Sat, 29 Aug 2020 at 00:51, Utkarsh Rai  wrote:
>>> >
>>> >
>>> >
>>> > On Sat, Aug 29, 2020 at 4:18 AM Gedare Bloom  wrote:
>>> >>
>>> >> Similarly, I would like to have a consolidated set of links to "your
>>> >> code" instead of having them woven in with the narrative and links to
>>> >> blogs etc.
>>> >>
>>> >
>>> > Ok, I will do that.
>>> >
>>> >>
>>> >> On Thu, Aug 27, 2020 at 6:33 PM Utkarsh Rai  
>>> >> wrote:
>>> >> >
>>> >> > Hello,
>>> >> > I have prepared a tentative final report for my project. You can view 
>>> >> > it here. Note there are few changes to be made in the report based on 
>>> >> > my progress this week as I am working on static initialization of PMP 
>>> >> > and the v5 patch for thread-stack isolation and sharing.
>>> >> > ___
>>> >> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 7/7] rtems: Add rtems_task_build()

[Gedare Bloom]

On Sun, Aug 30, 2020 at 8:50 AM Sebastian Huber
 wrote:
>
> On 22/08/2020 09:49, Chris Johns wrote:
>
> > On 21/8/20 9:51 pm, Sebastian Huber wrote:
> >> In contrast to rtems_task_create() this function creates a task with a
> >> user-provided task storage area.
> > The name is build but it creates a task? I am wondering about
> > rtems_task_create_static or something along this line?
>
> A function to do a static initialization is a contradiction from my
> point of view. Static initialization means for me that you statically
> initialize a data structure and then it is ready to use (it may involve
> a static constructor).
>
> The function builds a task from user-provided (stack, attributes, etc.)
> and system-provided (thread control block) components.
>

yes, as a technical term we usually take "static" to mean something
done at compile/build time.

> >
> >> Close #3959.
> > Sorry, I had not read the ticket's details.
>
> There is a similar ticket for message queues:
>
> https://devel.rtems.org/ticket/4007
>
> >
> > Chris
> >
> >> ---
> >>   cpukit/Makefile.am |   1 +
> >>   cpukit/include/rtems/rtems/tasks.h |  65 ++
> >>   cpukit/include/rtems/rtems/tasksimpl.h |  11 +
> >>   cpukit/rtems/src/taskbuild.c   | 273 
> >>   cpukit/rtems/src/taskcreate.c  | 274 +
> >>   testsuites/sptests/sp01/init.c |  22 +-
> >>   testsuites/sptests/sp01/sp01.doc   |   1 +
> >>   testsuites/sptests/sp01/system.h   |   2 +-
> >>   8 files changed, 413 insertions(+), 236 deletions(-)
> >>   create mode 100644 cpukit/rtems/src/taskbuild.c
> >>
> >> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> >> index bc56822cf8..e382478eac 100644
> >> --- a/cpukit/Makefile.am
> >> +++ b/cpukit/Makefile.am
> >> @@ -785,6 +785,7 @@ librtemscpu_a_SOURCES += rtems/src/statustext.c
> >>   librtemscpu_a_SOURCES += rtems/src/statustoerrno.c
> >>   librtemscpu_a_SOURCES += rtems/src/systemeventreceive.c
> >>   librtemscpu_a_SOURCES += rtems/src/systemeventsend.c
> >> +librtemscpu_a_SOURCES += rtems/src/taskbuild.c
> >>   librtemscpu_a_SOURCES += rtems/src/taskcreate.c
> >>   librtemscpu_a_SOURCES += rtems/src/taskdelete.c
> >>   librtemscpu_a_SOURCES += rtems/src/taskexit.c
> >> diff --git a/cpukit/include/rtems/rtems/tasks.h 
> >> b/cpukit/include/rtems/rtems/tasks.h
> >> index 12c323e60e..dff811686a 100644
> >> --- a/cpukit/include/rtems/rtems/tasks.h
> >> +++ b/cpukit/include/rtems/rtems/tasks.h
> >> @@ -164,6 +164,71 @@ rtems_status_code rtems_task_create(
> >> [...]
> >> +  /**
> >> +   * @brief This member defines the optional handler to free the task 
> >> storage
> >> +   *   area.
> >> +   *
> >> +   * It may be NULL.
> >> +   */
> >> +  void ( *storage_free )( void * );
> > Called under what context? What can this call do? For example call the 
> > standard
> > heap allocator.
>
> This is a good question.  What about:
>
> @brief This member defines the optional handler to free the task storage
> area.
>
> It is called when the task building aborts due to a failed task create
> extension or the task is deleted. It is called from task context under
> protection of the object allocator lock. It is allowed to call free() in
> this handler.
>
> ___
> 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: [PATCH 00/16] c-user: Split up chapter files

[Gedare Bloom]

this is fairly mechanical. My only question is whether it is better to
keep the longer names for the directory. like... timer_manager/
instead of timer/  or to avoid abbreviations like rate_monotonic/
instead of ratemon/

There are two decisions here: whether or not to say manager in a
directory, and whether or not to abbreviate the subdirectory. There's
not really a right answer, and it doesn't matter greatly, so you can
just push it how it is if you prefer.

-Gedare
On Thu, Aug 20, 2020 at 4:19 AM Sebastian Huber
 wrote:
>
> This patch set is a preparation to automatically generate parts of the
> documentation (introduction.rst and directives.rst) in the future from
> specification items.
>
> Sebastian Huber (16):
>   c-user: Split up semaphore manager
>   c-user: Split up event manager
>   c-user: Split up barrier manager
>   c-user: Split up clock manager
>   c-user: Split up dual-ported memory manager
>   c-user: Split up interrupt manager
>   c-user: Split up IO manager
>   c-user: Split up message manager
>   c-user: Split up partition manager
>   c-user: Split up rate-monotonic manager
>   c-user: Split up region manager
>   c-user: Split up signal manager
>   c-user: Split up task manager
>   c-user: Split up timer manager
>   c-user: Split up user extensions manager
>   c-user: Split up scheduling concepts
>
>  c-user/barrier/background.rst |   68 +
>  .../directives.rst}   |  169 +--
>  c-user/barrier/index.rst  |   14 +
>  c-user/barrier/introduction.rst   |   20 +
>  c-user/barrier/operations.rst |   60 +
>  c-user/clock/background.rst   |   96 ++
>  .../directives.rst}   |  238 +---
>  c-user/clock/index.rst|   15 +
>  c-user/clock/introduction.rst |   36 +
>  c-user/clock/operations.rst   |   78 ++
>  c-user/dpmem/background.rst   |   23 +
>  .../directives.rst}   |   84 --
>  c-user/dpmem/index.rst|   16 +
>  c-user/dpmem/introduction.rst |   20 +
>  c-user/dpmem/operations.rst   |   44 +
>  c-user/event/background.rst   |   96 ++
>  c-user/event/directives.rst   |  142 +++
>  c-user/event/index.rst|   15 +
>  c-user/event/introduction.rst |   13 +
>  c-user/event/operations.rst   |   63 +
>  c-user/event_manager.rst  |  309 -
>  c-user/index.rst  |   32 +-
>  c-user/intr/background.rst|  106 ++
>  .../directives.rst}   |  251 
>  c-user/intr/index.rst |   15 +
>  c-user/intr/introduction.rst  |   37 +
>  c-user/intr/operations.rst|  112 ++
>  c-user/io/background.rst  |  162 +++
>  c-user/{io_manager.rst => io/directives.rst}  |  215 
>  c-user/io/index.rst   |   16 +
>  c-user/io/introduction.rst|   30 +
>  c-user/io/operations.rst  |   26 +
>  c-user/message/background.rst |   91 ++
>  .../directives.rst}   |  205 
>  c-user/message/index.rst  |   16 +
>  c-user/message/introduction.rst   |   28 +
>  c-user/message/operations.rst |   89 ++
>  c-user/part/background.rst|   50 +
>  .../directives.rst}   |  120 --
>  c-user/part/index.rst |   15 +
>  c-user/part/introduction.rst  |   19 +
>  c-user/part/operations.rst|   55 +
>  c-user/rate_monotonic_manager.rst | 1091 -
>  c-user/ratemon/background.rst |  390 ++
>  c-user/ratemon/directives.rst |  474 +++
>  c-user/ratemon/index.rst  |   16 +
>  c-user/ratemon/introduction.rst   |   33 +
>  c-user/ratemon/operations.rst |  200 +++
>  c-user/region/background.rst  |   87 ++
>  .../directives.rst}   |  213 
>  c-user/region/index.rst   |   15 +
>  c-user/region/introduction.rst|   29 +
>  c-user/region/operations.rst  |  101 ++
>  c-user/sched/background.rst   |  327 +
>  c-user/sched/directives.rst   |  424 +++
>  c-user/sched/index.rst|   19 +
>  c-user/sched/introduction.rst |   42 +
>  c-user/sched/smp-schedulers.rst   |   69 ++
>  c-user/sched/uniprocessor-schedulers.rst  |  113 ++
>  c-user/scheduling_concepts.rst|  968 ---
>  c-user/sem/background.rst |  180 +++
>  .../directives.rst} 

Re: GSoC 2020 - Final project report

[Utkarsh Rai]

Thank you for your kind guidance throughout the GSoC period. My work with
this project through is not complete and I hope to get it finally merged
upstream and keep poking around even when that is done :).

On Sun, Aug 30, 2020 at 8:46 PM Gedare Bloom  wrote:

> Looks great
>
> On Sun, Aug 30, 2020 at 4:55 AM Utkarsh Rai 
> wrote:
> >
> > I have updated my post with the help of all of your suggestions. As
> @Niteesh G. S.  said, sorry to disturb you on a weekend but please take a
> look.
> >
> > On Sat, Aug 29, 2020 at 6:03 PM Utkarsh Rai 
> wrote:
> >>
> >>
> >>
> >> On Sat, Aug 29, 2020 at 3:59 PM Hesham Almatary <
> hesham.almat...@cl.cam.ac.uk> wrote:
> >>>
> >>> Hello Utkarsh,
> >>>
> >>> Thanks for the blog post. Are there any instructions on how can
> >>> someone (maybe a future GSoC student or someone else interested) get
> >>> your code tested (with test demos) and on which platform? A HOWTO
> >>> guide/blogpost will be great.
> >>
> >>
> >> Currently no, as there are a couple more tests that I want to get
> reviewed. I will update my post according to your suggestions by today
> >>
> >>>
> >>>
> >>> On Sat, 29 Aug 2020 at 00:51, Utkarsh Rai 
> wrote:
> >>> >
> >>> >
> >>> >
> >>> > On Sat, Aug 29, 2020 at 4:18 AM Gedare Bloom 
> wrote:
> >>> >>
> >>> >> Similarly, I would like to have a consolidated set of links to "your
> >>> >> code" instead of having them woven in with the narrative and links
> to
> >>> >> blogs etc.
> >>> >>
> >>> >
> >>> > Ok, I will do that.
> >>> >
> >>> >>
> >>> >> On Thu, Aug 27, 2020 at 6:33 PM Utkarsh Rai <
> utkarsh.ra...@gmail.com> wrote:
> >>> >> >
> >>> >> > Hello,
> >>> >> > I have prepared a tentative final report for my project. You can
> view it here. Note there are few changes to be made in the report based on
> my progress this week as I am working on static initialization of PMP and
> the v5 patch for thread-stack isolation and sharing.
> >>> >> > ___
> >>> >> > 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 00/16] c-user: Split up chapter files

[Joel Sherrill]

On Sun, Aug 30, 2020, 11:02 AM Joel Sherrill 
wrote:

>
>
> On Sun, Aug 30, 2020, 10:22 AM Gedare Bloom  wrote:
>
>> this is fairly mechanical. My only question is whether it is better to
>> keep the longer names for the directory. like... timer_manager/
>> instead of timer/  or to avoid abbreviations like rate_monotonic/
>> instead of ratemon/
>>
>
> Longer names and subdirectories please. It has worked in the Users Guide.
>
> We are long past 8.3 and 13 character name limits. Just avoid spaces and
> special characters in names and stick to all lower case.
>
>
>> There are two decisions here: whether or not to say manager in a
>> directory, and whether or not to abbreviate the subdirectory. There's
>> not really a right answer, and it doesn't matter greatly, so you can
>> just push it how it is if you prefer.
>>
>> -Gedare
>> On Thu, Aug 20, 2020 at 4:19 AM Sebastian Huber
>>  wrote:
>> >
>> > This patch set is a preparation to automatically generate parts of the
>> > documentation (introduction.rst and directives.rst) in the future from
>> > specification items.
>> >
>> > Sebastian Huber (16):
>> >   c-user: Split up semaphore manager
>> >   c-user: Split up event manager
>> >   c-user: Split up barrier manager
>> >   c-user: Split up clock manager
>> >   c-user: Split up dual-ported memory manager
>> >   c-user: Split up interrupt manager
>> >   c-user: Split up IO manager
>> >   c-user: Split up message manager
>> >   c-user: Split up partition manager
>> >   c-user: Split up rate-monotonic manager
>> >   c-user: Split up region manager
>> >   c-user: Split up signal manager
>> >   c-user: Split up task manager
>> >   c-user: Split up timer manager
>> >   c-user: Split up user extensions manager
>> >   c-user: Split up scheduling concepts
>> >
>> >  c-user/barrier/background.rst |   68 +
>> >  .../directives.rst}   |  169 +--
>> >  c-user/barrier/index.rst  |   14 +
>> >  c-user/barrier/introduction.rst   |   20 +
>> >  c-user/barrier/operations.rst |   60 +
>> >  c-user/clock/background.rst   |   96 ++
>> >  .../directives.rst}   |  238 +---
>> >  c-user/clock/index.rst|   15 +
>> >  c-user/clock/introduction.rst |   36 +
>> >  c-user/clock/operations.rst   |   78 ++
>> >  c-user/dpmem/background.rst   |   23 +
>> >  .../directives.rst}   |   84 --
>> >  c-user/dpmem/index.rst|   16 +
>> >  c-user/dpmem/introduction.rst |   20 +
>> >  c-user/dpmem/operations.rst   |   44 +
>> >  c-user/event/background.rst   |   96 ++
>> >  c-user/event/directives.rst   |  142 +++
>> >  c-user/event/index.rst|   15 +
>> >  c-user/event/introduction.rst |   13 +
>> >  c-user/event/operations.rst   |   63 +
>> >  c-user/event_manager.rst  |  309 -
>> >  c-user/index.rst  |   32 +-
>> >  c-user/intr/background.rst|  106 ++
>> >  .../directives.rst}   |  251 
>> >  c-user/intr/index.rst |   15 +
>> >  c-user/intr/introduction.rst  |   37 +
>> >  c-user/intr/operations.rst|  112 ++
>> >  c-user/io/background.rst  |  162 +++
>> >  c-user/{io_manager.rst => io/directives.rst}  |  215 
>> >  c-user/io/index.rst   |   16 +
>> >  c-user/io/introduction.rst|   30 +
>> >  c-user/io/operations.rst  |   26 +
>> >  c-user/message/background.rst |   91 ++
>> >  .../directives.rst}   |  205 
>> >  c-user/message/index.rst  |   16 +
>> >  c-user/message/introduction.rst   |   28 +
>> >  c-user/message/operations.rst |   89 ++
>> >  c-user/part/background.rst|   50 +
>> >  .../directives.rst}   |  120 --
>> >  c-user/part/index.rst |   15 +
>> >  c-user/part/introduction.rst  |   19 +
>> >  c-user/part/operations.rst|   55 +
>> >  c-user/rate_monotonic_manager.rst | 1091 -
>> >  c-user/ratemon/background.rst |  390 ++
>> >  c-user/ratemon/directives.rst |  474 +++
>> >  c-user/ratemon/index.rst  |   16 +
>> >  c-user/ratemon/introduction.rst   |   33 +
>> >  c-user/ratemon/operations.rst |  200 +++
>> >  c-user/region/background.rst  |   87 ++
>> >  .../directives.rst}   |  213 
>> >  c-user/region/index.rst   |   15 +
>> >  c-user/region/introduction.rst 

Re: GSoC 2020 - Final project report

[Gedare Bloom]

Utkarsh,

I'll be happy to continue to guide you in this work, subject to your
availability.

-Gedare

On Sun, Aug 30, 2020 at 9:25 AM Utkarsh Rai  wrote:
>
> Thank you for your kind guidance throughout the GSoC period. My work with 
> this project through is not complete and I hope to get it finally merged 
> upstream and keep poking around even when that is done :).
>
> On Sun, Aug 30, 2020 at 8:46 PM Gedare Bloom  wrote:
>>
>> Looks great
>>
>> On Sun, Aug 30, 2020 at 4:55 AM Utkarsh Rai  wrote:
>> >
>> > I have updated my post with the help of all of your suggestions. As 
>> > @Niteesh G. S.  said, sorry to disturb you on a weekend but please take a 
>> > look.
>> >
>> > On Sat, Aug 29, 2020 at 6:03 PM Utkarsh Rai  
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Sat, Aug 29, 2020 at 3:59 PM Hesham Almatary 
>> >>  wrote:
>> >>>
>> >>> Hello Utkarsh,
>> >>>
>> >>> Thanks for the blog post. Are there any instructions on how can
>> >>> someone (maybe a future GSoC student or someone else interested) get
>> >>> your code tested (with test demos) and on which platform? A HOWTO
>> >>> guide/blogpost will be great.
>> >>
>> >>
>> >> Currently no, as there are a couple more tests that I want to get 
>> >> reviewed. I will update my post according to your suggestions by today
>> >>
>> >>>
>> >>>
>> >>> On Sat, 29 Aug 2020 at 00:51, Utkarsh Rai  
>> >>> wrote:
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Sat, Aug 29, 2020 at 4:18 AM Gedare Bloom  wrote:
>> >>> >>
>> >>> >> Similarly, I would like to have a consolidated set of links to "your
>> >>> >> code" instead of having them woven in with the narrative and links to
>> >>> >> blogs etc.
>> >>> >>
>> >>> >
>> >>> > Ok, I will do that.
>> >>> >
>> >>> >>
>> >>> >> On Thu, Aug 27, 2020 at 6:33 PM Utkarsh Rai  
>> >>> >> wrote:
>> >>> >> >
>> >>> >> > Hello,
>> >>> >> > I have prepared a tentative final report for my project. You can 
>> >>> >> > view it here. Note there are few changes to be made in the report 
>> >>> >> > based on my progress this week as I am working on static 
>> >>> >> > initialization of PMP and the v5 patch for thread-stack isolation 
>> >>> >> > and sharing.
>> >>> >> > ___
>> >>> >> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 00/16] c-user: Split up chapter files

[Gedare Bloom]

On Sun, Aug 30, 2020 at 10:15 AM Joel Sherrill  wrote:
>
>
>
> On Sun, Aug 30, 2020, 11:02 AM Joel Sherrill  wrote:
>>
>>
>>
>> On Sun, Aug 30, 2020, 10:22 AM Gedare Bloom  wrote:
>>>
>>> this is fairly mechanical. My only question is whether it is better to
>>> keep the longer names for the directory. like... timer_manager/
>>> instead of timer/  or to avoid abbreviations like rate_monotonic/
>>> instead of ratemon/
>>
>>
>> Longer names and subdirectories please. It has worked in the Users Guide.
>>
>> We are long past 8.3 and 13 character name limits. Just avoid spaces and 
>> special characters in names and stick to all lower case.
>>

Should we explicitly say _manager on each of them though? Or it is ok
to say timer/ clock/ rate_monotonic/ and so on?

>>>
>>> There are two decisions here: whether or not to say manager in a
>>> directory, and whether or not to abbreviate the subdirectory. There's
>>> not really a right answer, and it doesn't matter greatly, so you can
>>> just push it how it is if you prefer.
>>>
>>> -Gedare
>>> On Thu, Aug 20, 2020 at 4:19 AM Sebastian Huber
>>>  wrote:
>>> >
>>> > This patch set is a preparation to automatically generate parts of the
>>> > documentation (introduction.rst and directives.rst) in the future from
>>> > specification items.
>>> >
>>> > Sebastian Huber (16):
>>> >   c-user: Split up semaphore manager
>>> >   c-user: Split up event manager
>>> >   c-user: Split up barrier manager
>>> >   c-user: Split up clock manager
>>> >   c-user: Split up dual-ported memory manager
>>> >   c-user: Split up interrupt manager
>>> >   c-user: Split up IO manager
>>> >   c-user: Split up message manager
>>> >   c-user: Split up partition manager
>>> >   c-user: Split up rate-monotonic manager
>>> >   c-user: Split up region manager
>>> >   c-user: Split up signal manager
>>> >   c-user: Split up task manager
>>> >   c-user: Split up timer manager
>>> >   c-user: Split up user extensions manager
>>> >   c-user: Split up scheduling concepts
>>> >
>>> >  c-user/barrier/background.rst |   68 +
>>> >  .../directives.rst}   |  169 +--
>>> >  c-user/barrier/index.rst  |   14 +
>>> >  c-user/barrier/introduction.rst   |   20 +
>>> >  c-user/barrier/operations.rst |   60 +
>>> >  c-user/clock/background.rst   |   96 ++
>>> >  .../directives.rst}   |  238 +---
>>> >  c-user/clock/index.rst|   15 +
>>> >  c-user/clock/introduction.rst |   36 +
>>> >  c-user/clock/operations.rst   |   78 ++
>>> >  c-user/dpmem/background.rst   |   23 +
>>> >  .../directives.rst}   |   84 --
>>> >  c-user/dpmem/index.rst|   16 +
>>> >  c-user/dpmem/introduction.rst |   20 +
>>> >  c-user/dpmem/operations.rst   |   44 +
>>> >  c-user/event/background.rst   |   96 ++
>>> >  c-user/event/directives.rst   |  142 +++
>>> >  c-user/event/index.rst|   15 +
>>> >  c-user/event/introduction.rst |   13 +
>>> >  c-user/event/operations.rst   |   63 +
>>> >  c-user/event_manager.rst  |  309 -
>>> >  c-user/index.rst  |   32 +-
>>> >  c-user/intr/background.rst|  106 ++
>>> >  .../directives.rst}   |  251 
>>> >  c-user/intr/index.rst |   15 +
>>> >  c-user/intr/introduction.rst  |   37 +
>>> >  c-user/intr/operations.rst|  112 ++
>>> >  c-user/io/background.rst  |  162 +++
>>> >  c-user/{io_manager.rst => io/directives.rst}  |  215 
>>> >  c-user/io/index.rst   |   16 +
>>> >  c-user/io/introduction.rst|   30 +
>>> >  c-user/io/operations.rst  |   26 +
>>> >  c-user/message/background.rst |   91 ++
>>> >  .../directives.rst}   |  205 
>>> >  c-user/message/index.rst  |   16 +
>>> >  c-user/message/introduction.rst   |   28 +
>>> >  c-user/message/operations.rst |   89 ++
>>> >  c-user/part/background.rst|   50 +
>>> >  .../directives.rst}   |  120 --
>>> >  c-user/part/index.rst |   15 +
>>> >  c-user/part/introduction.rst  |   19 +
>>> >  c-user/part/operations.rst|   55 +
>>> >  c-user/rate_monotonic_manager.rst | 1091 -
>>> >  c-user/ratemon/background.rst |  390 ++
>>> >  c-user/ratemon/directives.rst |  474 +++
>>> >  c-user/ratemon/index.rst  |   16 +
>>> >  c-user/ratemon/introduction.rst   |   33 +
>>> >  c-user/

Re: [PATCH 3/3] score: Optimize _Objects_Name_to_id_u32()

[Gedare Bloom]

On Fri, Aug 21, 2020 at 2:32 AM Sebastian Huber
 wrote:
>
> Remove the superfluous invalid name check since the object creation
> directives ensure that objects with such a name cannot exist.  Also

Should it instead be a (debug) assert?

> finding an object with such a name would be no catastrophy if it really
> exists.
> ---
>  cpukit/score/src/objectnametoid.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/cpukit/score/src/objectnametoid.c 
> b/cpukit/score/src/objectnametoid.c
> index d89e161c8c..2a71c6e528 100644
> --- a/cpukit/score/src/objectnametoid.c
> +++ b/cpukit/score/src/objectnametoid.c
> @@ -40,9 +40,6 @@ Objects_Name_or_id_lookup_errors _Objects_Name_to_id_u32(
>if ( !id )
>  return OBJECTS_INVALID_ADDRESS;
>
> -  if ( name == 0 )
> -return OBJECTS_INVALID_NAME;
> -
>maximum = _Objects_Get_maximum_index( information );
>search_local_node = false;
>
> --
> 2.26.2
>
> ___
> 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

Error in RISC-V Dynamic loading code

[Eshan Dhawan]

Hello everyone,
While testing my confstr patch on RISCV i received this error.

Error Log :
make[5]: Entering directory
'/home/eshan/development/rtems/kernel/rv32imac/riscv-rtems6/c/rv32imac/testsuites/libtests'
rtems-ld -r
/home/eshan/development/rtems/kernel/rv32imac/riscv-rtems6/c/rv32imac \
  -C riscv-rtems6-gcc -c "-march=rv32imac -mabi=ilp32" \
  -O rap -b dl06.pre -e rtems_main -s \
  -o dl06.rap dl06-o1.o dl06-o2.o -lm
error: rap::object: Section index '0' not found: dl06-o1.o
Makefile:8528: recipe for target 'dl06.rap' failed
make[5]: *** [dl06.rap] Error 10
make[5]: Leaving directory
'/home/eshan/development/rtems/kernel/rv32imac/riscv-rtems6/c/rv32imac/testsuites/libtests'
Makefile:663: recipe for target 'libtests' failed
make[4]: *** [libtests] Error 2
make[4]: Leaving directory
'/home/eshan/development/rtems/kernel/rv32imac/riscv-rtems6/c/rv32imac/testsuites'
Makefile:1222: recipe for target 'testsuites' failed
make[3]: *** [testsuites] Error 2
make[3]: Leaving directory
'/home/eshan/development/rtems/kernel/rv32imac/riscv-rtems6/c/rv32imac'
Makefile:716: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
'/home/eshan/development/rtems/kernel/rv32imac/riscv-rtems6/c/rv32imac'
Makefile:289: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/home/eshan/development/rtems/kernel/rv32imac/riscv-rtems6/c'
Makefile:410: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

-- 
Thanks
- Eshan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] tester: Change to a simpler TFTP server

[Chris Johns]

On 28/8/20 1:44 am, Gedare Bloom wrote:
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#python-file-template

I have reviewed the templates and I will post some minor changes. The Python one
should change ...

# File documentation block

to ...

''Module documentation block'''

The pylint tools points this out.

I have hit some issues with pylint, for example this pattern is not handled and
it is annoying:

   class foo:

   def __init__(self):
   self._reinit()

   def _reinit(self):
   self.bar = None

   def get_bar(self):
   # Attribute 'bar' \
   #  defined outside __init__ (attribute-defined-outside-init)
   return self.bar

   def restart(self):
   self._reinit()

I do not like the idea of directly calling __init__, maybe this is a C++ thing.

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

Re: [PATCH 7/7] rtems: Add rtems_task_build()

[Chris Johns]

On 31/8/20 12:49 am, Sebastian Huber wrote:
> On 22/08/2020 09:49, Chris Johns wrote:
> 
>> On 21/8/20 9:51 pm, Sebastian Huber wrote:
>>> In contrast to rtems_task_create() this function creates a task with a
>>> user-provided task storage area.
>> The name is build but it creates a task? I am wondering about
>> rtems_task_create_static or something along this line?
> 
> A function to do a static initialization is a contradiction from my point of
> view. Static initialization means for me that you statically initialize a data
> structure and then it is ready to use (it may involve a static constructor).
> 
> The function builds a task from user-provided (stack, attributes, etc.) and
> system-provided (thread control block) components.

Build and create are both verbs which means both contradict the idea of
something being static. By tradition we assume a function's naming is in the
run-time context and we do not consider the fact a compiler may optimise the
operation and prepare the result before the code runs.

I am concerned there maybe doubt about how the calls are to be used if you are
not familiar with the API and it's history. Do I need to create a task then
build it before I start it? The call names I proposed both create a task, one is
static and by default the other is not.

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

Re: [PATCH 00/16] c-user: Split up chapter files

[Chris Johns]

On 31/8/20 2:41 am, Gedare Bloom wrote:
> On Sun, Aug 30, 2020 at 10:15 AM Joel Sherrill  wrote:
>> On Sun, Aug 30, 2020, 11:02 AM Joel Sherrill  wrote:
>>> On Sun, Aug 30, 2020, 10:22 AM Gedare Bloom  wrote:

 this is fairly mechanical. My only question is whether it is better to
 keep the longer names for the directory. like... timer_manager/
 instead of timer/  or to avoid abbreviations like rate_monotonic/
 instead of ratemon/
>>>
>>> Longer names and subdirectories please. It has worked in the Users Guide.
>>>
>>> We are long past 8.3 and 13 character name limits. Just avoid spaces and 
>>> special characters in names and stick to all lower case.
>>>
> 
> Should we explicitly say _manager on each of them though? Or it is ok
> to say timer/ clock/ rate_monotonic/ and so on?

I agree, the _manager part is not needed and adds nothing.

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

[PATCH v2] tester: Change to a simpler TFTP server

[chrisj]

Hello,

The v2 patch has changed the template to a slightly modified version of the
one in the enginneering manual. The code has been yapf and pylint checked.

Chris

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

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Niteesh G. S.]

Hello,

I have submitted the final eval.

Thank you, everyone, for all the support throughout the project. Though I
couldn't
get any of my patches merged. I expect to spend a lot of time post-GSoC to
get
the work merged and contribute even more :).

Thanks,
Niteesh.
On Sun, Aug 30, 2020 at 8:46 PM Gedare Bloom  wrote:

> looks great
>
> On Sun, Aug 30, 2020 at 6:55 AM Christian Mauderer 
> wrote:
> >
> > On 30/08/2020 14:38, Niteesh G. S. wrote:
> > > Hello,
> > >
> > > On Sun, Aug 30, 2020 at 4:12 PM Christian Mauderer  > > > wrote:
> > >
> > > Hello Niteesh,
> > >
> > > On 30/08/2020 08:58, Niteesh G. S. wrote:
> > > > Hello,
> > > >
> > > > I have updated the blog to contain the links to the commits
> > > > instead of the branches. Please have a look again.
> > > > https://gs-niteesh.github.io/finalreport/
> > >
> > > >From my point of view, it looks good now. You missed the commit
> > > with the
> > > refactored i2c driver:
> > >
> > > Sorry about that. I fixed this.
> > >
> > >
> https://github.com/gs-niteesh/rtems/commit/be9bd605c40cf7cbcf3f527054fdbab2af39f52a
> > >
> > > But if you don't have time left it's not a problem if it isn't
> there.
> > >
> > > The Submission guidelines tell that "It must be easy to identify
> the
> > > work you have done." From my point of view that was already quite
> clear
> > > because the commits are all on top of the final branch. But Gedare
> is of
> > > course right: Linking every commit is a bit more clear.
> > >
> > >
> > > > And sorry to disturb on the weekend,  but we have only about
> > > > a day left before the submission deadline, so I request
> > > > everyone to please take a look and let me know if you would
> > > > like to change anything.
> > >
> > > No problem for disturbing in this case. Don't miss your deadline.
> It's
> > > better to submit something that is not perfect than not submitting
> > > anything. We would have no possibility to fix a missed submission.
> > >
> > >
> > > I have to submit it before tomorrow 11:30 PM IST. I'll leave it tonight
> > > for others to comment and will fill it tomorrow morning.
> >
> > Be really careful to not miss a deadline. Again: We have no chance of
> > fixing a missed deadline.
> >
> > Best regards
> >
> > Christian
> >
> > >
> > > Thanks,
> > > Niteesh.
> > >
> > >
> > > Best regards
> > >
> > > Christian
> > >
> > > >
> > > > Thanks,
> > > > Niteesh.
> > > >
> > > > On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom  > > 
> > > > >> wrote:
> > > >
> > > > On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer
> > > > mailto:o...@c-mauderer.de>
> > > >> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 29/08/2020 15:04, Niteesh G. S. wrote:
> > > > > > Hello,
> > > > > > On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer
> > > > mailto:o...@c-mauderer.de>
> > > >
> > > > > > 
> > >  > > > > >
> > > > > > Hello Niteesh
> > > > > >
> > > > > > On 29/08/2020 11:22, Niteesh G. S. wrote:
> > > > > > > On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer
> > > > > > mailto:o...@c-mauderer.de>
> > > >
> > > > 
> > > >>
> > > > > > > 
> > > >
> > > > 
> > >  wrote:
> > > > > > >
> > > > > > > On 29/08/2020 05:57, Niteesh G. S. wrote:
> > > > > > > > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom
> > > > > > mailto:ged...@rtems.org>
> > > >
> > > > 
> > > >>
> > > > > > >  > >   > > >
> > > > 
> > >  > > > > > > >  > >   > > >
> > > >  

Re: [PATCH 7/7] rtems: Add rtems_task_build()

[Sebastian Huber]

On 31/08/2020 02:34, Chris Johns wrote:


On 31/8/20 12:49 am, Sebastian Huber wrote:

On 22/08/2020 09:49, Chris Johns wrote:


On 21/8/20 9:51 pm, Sebastian Huber wrote:

In contrast to rtems_task_create() this function creates a task with a
user-provided task storage area.

The name is build but it creates a task? I am wondering about
rtems_task_create_static or something along this line?

A function to do a static initialization is a contradiction from my point of
view. Static initialization means for me that you statically initialize a data
structure and then it is ready to use (it may involve a static constructor).

The function builds a task from user-provided (stack, attributes, etc.) and
system-provided (thread control block) components.

Build and create are both verbs which means both contradict the idea of
something being static. By tradition we assume a function's naming is in the
run-time context and we do not consider the fact a compiler may optimise the
operation and prepare the result before the code runs.
Yes, the task creation or building through a function call is not a 
static initialization. This is why I don't like rtems_task_create_static().


I am concerned there maybe doubt about how the calls are to be used if you are
not familiar with the API and it's history. Do I need to create a task then
build it before I start it?
Yes, such a confusion is possible, but I think this can be solved by the 
documentation. Also both functions return an identifier. You cannot use 
them with an identifier.

The call names I proposed both create a task, one is
static and by default the other is not.


If you really want something with create in it, then I suggest 
rtems_task_create_with_config() and 
rtems_message_queue_create_with_config(). I think these names are a bit 
long.


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

Re: [PATCH 3/3] score: Optimize _Objects_Name_to_id_u32()

[Sebastian Huber]

On 30/08/2020 18:42, Gedare Bloom wrote:


On Fri, Aug 21, 2020 at 2:32 AM Sebastian Huber
  wrote:

Remove the superfluous invalid name check since the object creation
directives ensure that objects with such a name cannot exist.  Also

Should it instead be a (debug) assert?


finding an object with such a name would be no catastrophy if it really
exists.

I add a debug assert to check that a found object has a valid name.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 00/16] c-user: Split up chapter files

[Sebastian Huber]

On 30/08/2020 18:41, Gedare Bloom wrote:


On Sun, Aug 30, 2020 at 10:15 AM Joel Sherrill  wrote:


On Sun, Aug 30, 2020, 11:02 AM Joel Sherrill  wrote:


On Sun, Aug 30, 2020, 10:22 AM Gedare Bloom  wrote:

this is fairly mechanical. My only question is whether it is better to
keep the longer names for the directory. like... timer_manager/
instead of timer/  or to avoid abbreviations like rate_monotonic/
instead of ratemon/

Longer names and subdirectories please. It has worked in the Users Guide.

We are long past 8.3 and 13 character name limits. Just avoid spaces and 
special characters in names and stick to all lower case.


Should we explicitly say _manager on each of them though? Or it is ok
to say timer/ clock/ rate_monotonic/ and so on?


If you prefer long names, then I would simply use the chapter names, for 
example "rate-monotonic-manager", "scheduling-concepts", etc.


The directory names of the patch correspond to the header file names in 
cpukit/include/rtems/rtems and I used them also for the specification:


https://git.rtems.org/rtems-central/tree/spec/req/rtems

https://git.rtems.org/rtems-central/tree/spec/if/rtems

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

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

Hello Niteesh,

On 31/08/2020 08:23, Niteesh G. S. wrote:
> Hello,
> 
> I have submitted the final eval.
> 
> Thank you, everyone, for all the support throughout the project.

Thank you for your work during GSoC 2020.

> Though I couldn't
> get any of my patches merged.

I'm sure we manage to do that soon (as soon as the new build system is
there).

> I expect to spend a lot of time post-GSoC
> to get
> the work merged and contribute even more :).

That would be great. Feel free to continue asking any questions that you
have.

Best regards

Christian

> 
> Thanks,
> Niteesh. 
> On Sun, Aug 30, 2020 at 8:46 PM Gedare Bloom  > wrote:
> 
> looks great
> 
> On Sun, Aug 30, 2020 at 6:55 AM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> >
> > On 30/08/2020 14:38, Niteesh G. S. wrote:
> > > Hello,
> > >
> > > On Sun, Aug 30, 2020 at 4:12 PM Christian Mauderer
> mailto:o...@c-mauderer.de>
> > > >> wrote:
> > >
> > >     Hello Niteesh,
> > >
> > >     On 30/08/2020 08:58, Niteesh G. S. wrote:
> > >     > Hello,
> > >     >
> > >     > I have updated the blog to contain the links to the commits
> > >     > instead of the branches. Please have a look again.
> > >     > https://gs-niteesh.github.io/finalreport/
> > >
> > >     >From my point of view, it looks good now. You missed the commit
> > >     with the
> > >     refactored i2c driver:
> > >
> > > Sorry about that. I fixed this.
> > >
> > >   
>  
> https://github.com/gs-niteesh/rtems/commit/be9bd605c40cf7cbcf3f527054fdbab2af39f52a
> > >
> > >     But if you don't have time left it's not a problem if it
> isn't there.
> > >
> > >     The Submission guidelines tell that "It must be easy to
> identify the
> > >     work you have done." From my point of view that was already
> quite clear
> > >     because the commits are all on top of the final branch. But
> Gedare is of
> > >     course right: Linking every commit is a bit more clear.
> > >
> > >
> > >     > And sorry to disturb on the weekend,  but we have only about
> > >     > a day left before the submission deadline, so I request
> > >     > everyone to please take a look and let me know if you would
> > >     > like to change anything.
> > >
> > >     No problem for disturbing in this case. Don't miss your
> deadline. It's
> > >     better to submit something that is not perfect than not
> submitting
> > >     anything. We would have no possibility to fix a missed
> submission.
> > >
> > >
> > > I have to submit it before tomorrow 11:30 PM IST. I'll leave it
> tonight
> > > for others to comment and will fill it tomorrow morning.
> >
> > Be really careful to not miss a deadline. Again: We have no chance of
> > fixing a missed deadline.
> >
> > Best regards
> >
> > Christian
> >
> > >
> > > Thanks,
> > > Niteesh.
> > >
> > >
> > >     Best regards
> > >
> > >     Christian
> > >
> > >     >
> > >     > Thanks,
> > >     > Niteesh.
> > >     >
> > >     > On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom
> mailto:ged...@rtems.org>
> > >     >
> > >     > 
>  > >     >
> > >     >     On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer
> > >     >     mailto:o...@c-mauderer.de>
> >
> > >     
>  > >     >     >
> > >     >     >
> > >     >     >
> > >     >     > On 29/08/2020 15:04, Niteesh G. S. wrote:
> > >     >     > > Hello,
> > >     >     > > On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer
> > >     >     mailto:o...@c-mauderer.de>
> >
> > >     
> >>
> > >     >     > >    >
> > >     
>  wrote:
> > >     >     > >
> > >     >     > >     Hello Niteesh
> > >     >     > >
> > >     >     > >     On 29/08/2020 11:22, Niteesh G. S. wrote:
> > >     >     > >     > On Sat, Aug 29, 2020 at 1:02 PM Christian
> Mauderer
> > >     >     > >     mailto:o...@c-mauderer.de>
>