On 29/7/21 8:44 am, Chris Johns wrote:
> On 28/7/21 4:44 pm, Sebastian Huber wrote:
>> On 28/07/2021 08:43, Chris Johns wrote:
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_
On 28/7/21 4:44 pm, Sebastian Huber wrote:
> On 28/07/2021 08:43, Chris Johns wrote:
>>> 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 plac
On 28/07/2021 08:43, Chris Johns wrote:
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,
tha
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 wrote:
From: Chris Johns
Update #4475
>>> This change could probably use its own ticket.
>> Without the change the RPC
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 wrote:
From: Chris Johns
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 ma
On 28/7/21 7:38 am, Gedare Bloom wrote:
> On Tue, Jul 27, 2021 at 2:59 AM wrote:
>>
>> From: Chris Johns
>>
>> 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
On Tue, Jul 27, 2021 at 2:59 AM wrote:
>
> From: Chris Johns
>
> Update #4475
This change could probably use its own ticket.
> ---
> rtemsbsd/rtems/rtems-kernel-timesupport.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/rtemsbsd/rtems/rtems-kernel-timesupport.
