On 04/03/16 20:12, Joel Sherrill wrote:
On Fri, Mar 4, 2016 at 12:25 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
