[PATCH v2] score: PR2136: Fix _Thread_Change_priority()

[Wendell Silva]

What about the cost of stacking an argument which is not used often?
Just wondering...

--Wendell


2013/8/12 Sebastian Huber <sebastian.huber at embedded-brains.de>

> On 2013-08-12 16:11, Gedare Bloom wrote:
>
>> On Fri, Aug 9, 2013 at 2:35 AM, Sebastian Huber
>> <sebastian.huber at embedded-**brains.de<sebastian.huber at embedded-brains.de>>
>> wrote:
>> <snip>
>>
>>> @@ -59,10 +60,12 @@ void _Scheduler_Handler_**initialization( void );
>>>    *
>>>    * This kernel routine implements the scheduling decision logic for
>>>    * the scheduler. It does NOT dispatch.
>>> + *
>>> + * @param[in] thread The thread which state changed previously.
>>>    */
>>> -RTEMS_INLINE_ROUTINE void _Scheduler_Schedule( void )
>>> +RTEMS_INLINE_ROUTINE void _Scheduler_Schedule( Thread_Control *thread )
>>>   {
>>> -  _Scheduler.Operations.**schedule();
>>> +  _Scheduler.Operations.**schedule( thread );
>>>   }
>>>
>>>  Can this "thread" parameter be used to "Update" the per-thread
>> scheduler metadata and obviate the call to _Scheduler_Update?
>>
>> -Gedare
>>
>>
> An optimized version of the current scheduler will use this thread
> parameter to get some state information.
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-**brains.de<sebastian.huber at embedded-brains.de>
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ______________________________**_________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130812/129c193b/attachment-0001.html>