[PATCH 8/8] score: Replace watchdog handler implementation
Joel Sherrill
joel at rtems.org
Fri Mar 4 19:12:55 UTC 2016
On Fri, Mar 4, 2016 at 12:25 AM, Sebastian Huber <
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.
--joel
> --
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160304/ed6cc3e2/attachment-0002.html>
More information about the devel
mailing list