On 19/07/16 17:18, Pavel Pisa wrote:
Hello Sebastian,
thanks for the comments
On Tuesday 19 of July 2016 11:48:07 Sebastian Huber wrote:
Hello Pavel,
On 14/07/16 15:04, Pavel Pisa wrote:
The overflow of 64-bit ticks and 34 bit for seconds packed timespec
format is not probable but I would like to see support for infinite
operation there even if it cost halving range of the most distant
timeouts.
with the 34-bits for seconds, we have a year 2514 problem. The 64-bit
ticks counter overflows with a 1ns tick interval in about 586 years. So,
nothing to worry about from my point of view.
I agree that it is not practically required.
Please, can you clarify, if packed timespec format
is used for both queues
PER_CPU_WATCHDOG_RELATIVE,
No, the PER_CPU_WATCHDOG_RELATIVE use a 64-bit ticks value.
PER_CPU_WATCHDOG_ABSOLUTE,
(my initial reading is that they use different
encoding) and if PER_CPU_WATCHDOG_RELATIVE can be
considered as CLOCK_MONOTONIC and real time clocks
corrections go only to PER_CPU_WATCHDOG_ABSOLUTE.
Best wishes,
Pavel
PS: have you some remarks to my cache and RPI series
or it can be pushes.
I move currently to a new house and I am only sporadically available. If
you don't hear something within three work days in general, then please
go ahead and commit whatever you think is best. I things break, then we
can fix it.
--
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
