On Tue, Oct 6, 2020 at 4:58 PM Chris Johns wrote:
> On 7/10/20 12:33 am, Joel Sherrill wrote:
> > One last pile on.
>
> No problem and thanks. The reviews are great.
>
> > It is minor but you said "scheduler modes" for
> > inherit/explicit. I couldn't place what bothered me about that wording.
>
On 7/10/20 12:33 am, Joel Sherrill wrote:
> One last pile on.
No problem and thanks. The reviews are great.
> It is minor but you said "scheduler modes" for
> inherit/explicit. I couldn't place what bothered me about that wording. This
> morning it hit me that modes is a Classic API term. I thi
On 6/10/20 5:12 pm, Sebastian Huber wrote:
> thanks, looks good.
Great :)
> I would have added the stuff to similar to
>
That is a great idea. I did not like `c++` in the path but I also did not think
`rtems/thread` was suitable.
> but this is a matter of taste.
I do not like .hpp as an exte
One last pile on. It is minor but you said "scheduler modes" for
inherit/explicit. I couldn't place what bothered me about that wording.
This morning it hit me that modes is a Classic API term. I think your
comments could talk about it in these terms and use the POSIX terms like
scheduling attribu
Hello Chris,
thanks, looks good.
I would have added the stuff to similar to
, but this is a matter of taste.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
From: Chris Johns
---
cpukit/include/rtems/c++/error| 69
cpukit/include/rtems/c++/thread | 476 ++
cpukit/librtemscxx/error.cc | 76
cpukit/librtemscxx/thread.cc | 416 +++
spec/build/cpukit/grp.yml
