[PATCH 8/8] score: Replace watchdog handler implementation

[Sebastian Huber]

On 04/03/16 20:12, Joel Sherrill wrote:
>
>
> On Fri, Mar 4, 2016 at 12:25 AM, Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>
>
>     On 03/03/16 23:44, Joel Sherrill wrote:
>
>
>             >
>             > "be placed on Red-Black Trees for set management."
>         copy-pasted
>             comment
>             > should be Chains?
>
>             Thanks, for spotting this.
>
>             >
>             > "watchdog is scheduled and a black node". ditto, black
>         should be red
>             > for the second one.
>
>             Oh, yes.
>
>             >
>             > _Watchdog_Ticks_from_seconds(): why is ticks =
>         seconds<<30 the right
>             > thing to do? Same for _Watchdog_Ticks_from_timespec(). I
>         am missing
>             > some assumption here, I guess. It might improve
>         readability to
>             provide
>             > a helper function for this.
>
>             Ok, sorry for the magic numbers.  2**30 == 1073741824
>         enough to
>             cope with 1e9 nanoseconds.  So, we have 2**34 seconds
>         available,
>             leading to a year 2514 problem.
>
>
>         That's pretty close to the 2^64 nanosecond limit as I recall.
>         So reasonable but
>         I suppose that should be very explicit somewhere in a comment.
>
>         Funny, before there was a wiki, we had a FAQ document which
>         had a section on
>         date/time overflow issues. We probably need a section in the
>         users manual with
>         the current truth on this:
>
>         https://docs.rtems.org/releases/rtemsdocs-4.6.4/share/rtems/html/FAQ/FAQ00100.html
>
>         We have multiple date/time and interval representations in the
>         score, classic and
>         POSIX APIs. It would be good to capture them again.
>
>
>     Yes, this is on my TODO list along with the year 2038 problem.
>
>
> I thought we had discussed on newlib just changing time_t to 64 bits 
> for RTEMS.
> But clearly the code still has it as a long.
>
> That seems to be the most straightforward solution.

I added a ticket for this:

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

-- 
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
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.