Re: [PATCH] [RSB] rtems-all.bset: add rtems-epiphany
On Fri, May 15, 2015 at 9:02 PM, Gedare Bloom wrote: > What about h8300? > Don't know about it and why it's not there, I can add it if that won't cause a problem. > On Fri, May 15, 2015 at 7:51 AM, Hesham ALMatary > wrote: >> --- >> rtems/config/4.11/rtems-all.bset | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/rtems/config/4.11/rtems-all.bset >> b/rtems/config/4.11/rtems-all.bset >> index 8a0fe82..6897e11 100644 >> --- a/rtems/config/4.11/rtems-all.bset >> +++ b/rtems/config/4.11/rtems-all.bset >> @@ -5,6 +5,7 @@ >> 4.11/rtems-arm >> 4.11/rtems-avr >> 4.11/rtems-bfin >> +4.11/rtems-epiphany >> 4.11/rtems-i386 >> 4.11/rtems-lm32 >> 4.11/rtems-m32c >> -- >> 2.1.0 >> >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 18/45] score: Add Thread_queue_Control::Lock
On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber wrote: > Move the complete thread queue enqueue procedure into > _Thread_queue_Enqueue_critical(). It is possible to use the thread > queue lock to protect state of the object embedding the thread queue. > This enables per object fine grained locking in the future. > > Delete _Thread_queue_Enter_critical_section(). > > Update #2273. > --- > + _Thread_queue_Destory( &the_condition_variable->Wait_queue ); Typo, Destory. Find/Replace all. [...] > /** > - * @brief Gets a pointer to the "first" thread on the_thread_queue. > + * @brief Returns the first thread on the thread queue if it exists, > otherwise > + * @c NULL (locked). > + * > + * The caller must be the owner of the thread queue lock. > + * > + * @param[in] the_thread_queue The thread queue. > * > - * This function returns a pointer to the "first" thread > - * on the_thread_queue. The "first" thread is selected > - * based on the discipline of the_thread_queue. > + * @retval NULL No thread is present on the thread queue. > + * @retval first The first thread on the thread queue according to the > enqueue > + * order. > + */ > +Thread_Control *_Thread_queue_First_locked( > + Thread_queue_Control *the_thread_queue > +); > + In other places we call such a function variant _unprotected. In the doxygen, I don't know what you mean by @c NULL (locked) in the @brief, or why there are two @brief. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 20/45] score: More thread queue operations
On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber
wrote:
> Move thread queue discipline specific operations into
> Thread_queue_Operations. Use a separate node in the thread control
> block for the thread queue to make it independent of the scheduler data
> structures.
>
> Update #2273.
> ---
[...]
> const Thread_queue_Operations _Thread_queue_Operations_default = {
> - .priority_change = _Thread_queue_Do_nothing_priority_change
> + .priority_change = _Thread_queue_Do_nothing_priority_change,
> + .extract = _Thread_queue_Do_nothing_extract
> };
>
Any reason not to set default values for the other operations? Or
explicitly to NULL?
> const Thread_queue_Operations _Thread_queue_Operations_FIFO = {
> - .priority_change = _Thread_queue_Do_nothing_priority_change
> + .priority_change = _Thread_queue_Do_nothing_priority_change,
> + .initialize = _Thread_queue_FIFO_initialize,
> + .enqueue = _Thread_queue_FIFO_enqueue,
> + .dequeue = _Thread_queue_FIFO_dequeue,
> + .extract = _Thread_queue_FIFO_extract,
> + .first = _Thread_queue_FIFO_first
> };
>
> const Thread_queue_Operations _Thread_queue_Operations_priority = {
> - .priority_change = _Thread_queue_Priority_priority_change
> + .priority_change = _Thread_queue_Priority_priority_change,
> + .initialize = _Thread_queue_Priority_initialize,
> + .enqueue = _Thread_queue_Priority_enqueue,
> + .dequeue = _Thread_queue_Priority_dequeue,
> + .extract = _Thread_queue_Priority_extract,
> + .first = _Thread_queue_Priority_first
> };
Would it make sense to separate the _Thread_queue_Priority operations
to their own file?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 18/45] score: Add Thread_queue_Control::Lock
On Sun, May 17, 2015 at 7:04 AM, Gedare Bloom wrote: > On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber > wrote: >> /** >> - * @brief Gets a pointer to the "first" thread on the_thread_queue. >> + * @brief Returns the first thread on the thread queue if it exists, >> otherwise >> + * @c NULL (locked). >> + * >> + * The caller must be the owner of the thread queue lock. >> + * >> + * @param[in] the_thread_queue The thread queue. >> * >> - * This function returns a pointer to the "first" thread >> - * on the_thread_queue. The "first" thread is selected >> - * based on the discipline of the_thread_queue. >> + * @retval NULL No thread is present on the thread queue. >> + * @retval first The first thread on the thread queue according to the >> enqueue >> + * order. >> + */ >> +Thread_Control *_Thread_queue_First_locked( >> + Thread_queue_Control *the_thread_queue >> +); >> + > In other places we call such a function variant _unprotected. In the > doxygen, I don't know what you mean by @c NULL (locked) in the @brief, > or why there are two @brief. Please clarify the distinctions between _locked(), _critical(), and _unprotected(). ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 24/45] score: Fine grained locking for message queues
On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber wrote: > Aggregate several critical sections into a bigger one. Sending and > receiving messages is now protected by an ISR lock. Thread dispatching > is only disabled in case a blocking operation is necessary. The message > copy procedure is done inside the critical section (interrupts > disabled). Thus this change may have a negative impact on the interrupt > latency in case very large messages are transferred. > > Update #2273. > --- > diff --git a/doc/user/msg.t b/doc/user/msg.t > index f58d677..4ca5611 100644 > --- a/doc/user/msg.t > +++ b/doc/user/msg.t > @@ -50,7 +50,10 @@ wait for a message to arrive at a queue. Also, a task may > poll > a queue for the arrival of a message. > > The maximum length message which can be sent is set > -on a per message queue basis. > +on a per message queue basis. The message content must be copied in general > +to/from an internal buffer of the message queue or directly to a peer in > +certain cases. This copy operation is performed with interrupts disabled. > So > +it is advisible to keep the messages as short as possible. s/advisible/advisable Thanks for making this note. Do we have any documentation that lists all the kinds of factors that affect the interrupt-disabled time? That would be "nice to have". ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 30/45] score: Rework _Thread_Change_priority()
On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber
wrote:
> Move the writes to Thread_Control::current_priority and
> Thread_Control::real_priority into _Thread_Change_priority() under the
> protection of the thread lock. Add a filter function to
> _Thread_Change_priority() to enable specialized variants.
>
> Avoid race conditions during a thread priority restore with the new
> Thread_Control::priority_restore_hint for an important average case
> optimizations used by priority inheritance mutexes.
>
> Update #2273.
> ---
> @@ -653,9 +676,21 @@ struct Thread_Control_struct {
>Objects_Control Object;
>/** This field is the current execution state of this thread. */
>States_Control current_state;
> - /** This field is the current priority state of this thread. */
> +
> + /**
> + * @brief This field is the current priority state of this thread.
> + *
> + * Writes to this field are only allowed in _Thread_Initialize() or via
> + * _Thread_Change_priority().
> + */
>Priority_Control current_priority;
> - /** This field is the base priority of this thread. */
> +
> + /**
> + * @brief This field is the base priority of this thread.
> + *
> + * Writes to this field are only allowed in _Thread_Initialize() or via
> + * _Thread_Change_priority().
> + */
>Priority_Control real_priority;
>
>/**
> @@ -666,6 +701,17 @@ struct Thread_Control_struct {
> */
>uint32_t priority_generation;
>
> + /**
> + * @brief Hints if a priority restore is necessary once the resource count
> + * changes from one to zero.
> + *
> + * This is an optimization to speed up the mutex surrender sequence in case
> + * no attempt to change the priority was made during the mutex ownership.
> On
> + * SMP configurations atomic fences must synchronize writes to
> + * Thread_Control::priority_restore_hint and
> Thread_Control::resource_count.
> + */
> + bool priority_restore_hint;
> +
In case of nested mutex acquires this will only work for the
inner-most acquire. The problem is a general issue (#2124) we have
with current priority inheritance. I don't think the optimization is
introducing a new priority inversion, but care must be taken when
using nested mutexes until we fix #2124.
Fixing #2124 may be facilitated by the changes made here to add
filters since the filter can update the priority more intelligently
for the nested mutex cases. This probably requires adding multiple
Restore_priority filters.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 40/45] timecounter: Import from FreeBSD
On Fri, May 15, 2015 at 7:41 AM, Sebastian Huber wrote: > From: Alexander Krutwig > > Update #2271. > --- > cpukit/score/include/sys/_ffcounter.h | 42 + > cpukit/score/include/sys/timeffc.h| 389 +++ > cpukit/score/include/sys/timepps.h| 249 > cpukit/score/include/sys/timetc.h | 89 ++ > cpukit/score/include/sys/timex.h | 171 +++ > cpukit/score/src/kern_tc.c| 2039 > + > cpukit/score/src/opt_compat.h |0 > cpukit/score/src/opt_ffclock.h|0 > cpukit/score/src/opt_ntp.h|0 > 9 files changed, 2979 insertions(+) > create mode 100644 cpukit/score/include/sys/_ffcounter.h > create mode 100644 cpukit/score/include/sys/timeffc.h > create mode 100644 cpukit/score/include/sys/timepps.h > create mode 100644 cpukit/score/include/sys/timetc.h > create mode 100644 cpukit/score/include/sys/timex.h > create mode 100644 cpukit/score/src/kern_tc.c > create mode 100644 cpukit/score/src/opt_compat.h > create mode 100644 cpukit/score/src/opt_ffclock.h > create mode 100644 cpukit/score/src/opt_ntp.h > > diff --git a/cpukit/score/include/sys/_ffcounter.h > b/cpukit/score/include/sys/_ffcounter.h > new file mode 100644 > index 000..0d5864a > --- /dev/null > +++ b/cpukit/score/include/sys/_ffcounter.h > @@ -0,0 +1,42 @@ > +/*- > + * Copyright (c) 2011 The University of Melbourne > + * All rights reserved. > + * > + * This software was developed by Julien Ridoux at the University of > Melbourne > + * under sponsorship from the FreeBSD Foundation. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + *notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + *notice, this list of conditions and the following disclaimer in the > + *documentation and/or other materials provided with the distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT > + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > + * SUCH DAMAGE. > + * > + * $FreeBSD$ > + */ > + I assume the code in this commit is all directly imported from some FreeBSD so I'm not going to review it too closely, but I do have one question. How are we tracking the upstream version? Should we include the populated $FreeBSD$ tag (checked-out id)? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 41/45] timecounter: Use uint32_t instead of u_int
On Fri, May 15, 2015 at 7:47 AM, Sebastian Huber wrote: > From: Alexander Krutwig > > FreeBSD assumes that u_int is a 32-bit integer type. This is wrong for > some 16-bit targets supported by RTEMS. > > Update #2271. > --- Can we undef u_int and redefine it to uint32_t instead? This will be a more localized RTEMS-specific change. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTC patch for BBB
All, I am happy to merge this. On May 3, 2015 1:02 PM, "ragu nath" wrote: > Hi All, > > I have attached the RTC patch for BBB. I have addressed the comments > given for my earlier submission. > > I am having problems with sending patch using git send-email. I > understand this is the preferred way but I not able to send patch > using git send-email. I am behind a http proxy and git was not able to > configure the smtp server. I could not find any solutions in the net. > Is there any known solutions to this problem? For time being I am > attaching the patch. Meanwhile I will also try to figure out the > solution for this problem > > > > Thanks, > Ragunath > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTC patch for BBB
On May 17, 2015 2:55:18 PM CDT, Ben Gras wrote: >All, > >I am happy to merge this. Go ahead and push this Ben. Post what you tried for git send-email minus the password. Someone might spit the issue. > >On May 3, 2015 1:02 PM, "ragu nath" wrote: > >Hi All, > >I have attached the RTC patch for BBB. I have addressed the comments >given for my earlier submission. > >I am having problems with sending patch using git send-email. I >understand this is the preferred way but I not able to send patch >using git send-email. I am behind a http proxy and git was not able to >configure the smtp server. I could not find any solutions in the net. >Is there any known solutions to this problem? For time being I am >attaching the patch. Meanwhile I will also try to figure out the >solution for this problem > > > >Thanks, >Ragunath --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Generating ChangeLog from git
Hi I have found git commands for generating reasonably formatted GNU style ChangeLogs. I don't seem to be able to make them print the changes from when 4.10 branched until now. This appears to be a combination of git rev-list to get the hash where the branch happened and git log. The git rev-list is giving me gits. Basically a ChangeLog needs to be between two points and I can't figure out how to (a) determine the two points in git and (b) specify them to git log. Any advice? --joel -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Generating ChangeLog from git
I basically use: $ git log $end $start where $end and $start can be a tag or a hash commit ID. regards On Sun, May 17, 2015 at 5:35 PM, Joel Sherrill wrote: > Hi > > I have found git commands for generating reasonably formatted GNU > style ChangeLogs. I don't seem to be able to make them print the changes > from when 4.10 branched until now. > > This appears to be a combination of git rev-list to get the hash where > the branch happened and git log. The git rev-list is giving me gits. > > Basically a ChangeLog needs to be between two points and I can't > figure out how to (a) determine the two points in git and (b) specify > them to git log. > > Any advice? > > --joel > > -- > Joel Sherrill, Ph.D. Director of Research & > developmentjoel.sherr...@oarcorp.comOn-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available(256) 722-9985 > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > -- Eduardo Silva Monkey Software ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
