On 28/7/21 4:03 pm, Sebastian Huber wrote: > 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 >
I am fixing the code that exists. I have no idea why kern_clock.c was not ported in the first place. I will not be porting the clock code at this point in time, that is out of scope for my current work. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
