[PATCH 6/7] score: Always validate ticks in _TOD_Validate()

Chris Johns chrisj at rtems.org
Sat Sep 4 05:21:36 UTC 2021


On 4/9/21 2:20 pm, Joel Sherrill wrote:
 On Fri, Sep 3, 2021, 11:01 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
> 
>     On 3/9/21 11:33 pm, Sebastian Huber wrote:
>     > The behaviour with respect to the handling of the ticks member in the *_when()
>     > directives was inconsistent.  In all *_when() directives the ticks member is
>     > not used to calculate the watchdog expiration time.  However, the
>     > rtems_task_wake_when() directive ignores the ticks member of the time of day
>     > completely, unlike the rtems_timer_fire_when() and
>     > rtems_timer_server_fire_when() directives which check that the ticks are valid
>     > and then ignore them.
>     >
>     > This commit changes _TOD_Validate() to unconditionally check the ticks value.
>     > Ignoring the value would make it more difficult to support the ticks in the
>     > future.  The watchdog implementation supports a nanoseconds resolution.
>     > Checking the ticks in rtems_task_wake_when() may case problems for existing
>     > applications which could now get an error status due to an invalid ticks
>     value.
>     >
>     > Applications should set the ticks value to zero for future compatibility. 
>     This
>     > recommendation needs to be added to the documentation.
> 
>     What happens with existing applications that do not touch this value?
> 
> 
> Randomly different behaviour.
> 
> Before all _when operations occurred on seconds boundaries.  This will
> implicitly change that or return an error.
> 
> I'm not opposed to the improved granularity but hope it doesn't burn too many users.

What about the proposed behaviour being the default and a confdefs disable
being available for a release? Updating to a new version can be time consuming
and frustrating and a disable would at least let a user see if this is an issue
they need to take care of at a less pressured time?

Chris


More information about the devel mailing list