On 28/07/2021 00:53, Chris Johns wrote:
On 28/7/21 7:38 am, Gedare Bloom wrote:
On Tue, Jul 27, 2021 at 2:59 AM<chr...@rtems.org> wrote:
From: Chris Johns<chr...@rtems.org>
Update #4475
This change could probably use its own ticket.
Without the change the RPC client fails to connect in a reliable way because the
connection may time out for no real reason. A connection that is stable appears
fragile. I used this ticket because the change was needed for NFS to work.
https://github.com/freebsd/freebsd-src/blob/main/sys/rpc/clnt_dg.c#L388
---
rtemsbsd/rtems/rtems-kernel-timesupport.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/rtemsbsd/rtems/rtems-kernel-timesupport.c
b/rtemsbsd/rtems/rtems-kernel-timesupport.c
index ef14d1fa..5d290d66 100644
--- a/rtemsbsd/rtems/rtems-kernel-timesupport.c
+++ b/rtemsbsd/rtems/rtems-kernel-timesupport.c
@@ -35,6 +35,7 @@
#include <machine/rtems-bsd-kernel-space.h>
+#include <limits.h>
#include <sys/time.h>
#include <rtems/score/timespec.h>
@@ -46,9 +47,14 @@ int
tvtohz(struct timeval *tv)
{
struct timespec ts;
+ uint32_t ticks;
ts.tv_sec = tv->tv_sec;
ts.tv_nsec = tv->tv_usec * 1000;
- return (int) _Timespec_To_ticks( &ts );
+ ticks = _Timespec_To_ticks( &ts );
+ if (ticks > INT_MAX)
+ ticks = INT_MAX;
+
This changes the behavior to saturating in the overflow case, which is
at least well-defined, but is it the best thing to do? (I have no
idea.)
I do not have a better suggestion? The user is providing a timeval that exceeds
the size of the return value so providing the max value at least the gets you
closer to the actual value than any other value?
Why don't we use the FreeBSD implementation one-to-one:
freebsd-org/sys/kern/kern_clock.c
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
