MIME-Version: 1.0
References: <1555105210-22996-1-git-send-email-greearb@candelatech.com>
 <1555105210-22996-2-git-send-email-greearb@candelatech.com>
 <CAOXD1ifE_rxU0fV6tXK2WpdOU2x9-b0J4cGsuqf3whi7YapBzA@mail.gmail.com>
 <ab7f61a1-0af6-a754-d9a0-388ebd0c8f15@candelatech.com> <CAOXD1icnusnOZ0b0n6eTD6PRoEcf_tHVgivmCEPM1KsWu1uEng@mail.gmail.com>
 <CAK8P3a2DVgneKY9XMQe_LFuECNR7qvLtJV-g-skC4EUDA40+-g@mail.gmail.com>
In-Reply-To: <CAK8P3a2DVgneKY9XMQe_LFuECNR7qvLtJV-g-skC4EUDA40+-g@mail.gmail.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Sat, 13 Apr 2019 10:04:30 +0200
Message-ID: <CAK8P3a0DrFs_17WyHXFqrxubZ8y3=JyirkV4LczRVkQMnRHZ5w@mail.gmail.com>
Subject: Re: [PATCH 2/2] iw: Print current time in station info dump
To:     Kirtika Ruchandani <kirtika@google.com>
Cc:     Ben Greear <greearb@candelatech.com>,
        linux-wireless <linux-wireless@vger.kernel.org>,
        Tina Ruchandani <ruchandani.tina@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Sat, Apr 13, 2019 at 10:00 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sat, Apr 13, 2019 at 12:07 AM Kirtika Ruchandani <kirtika@google.com> wrote:
> >
> > On Fri, Apr 12, 2019 at 2:49 PM Ben Greear <greearb@candelatech.com> wrote:
> > >
> > > On 4/12/19 2:43 PM, Kirtika Ruchandani wrote:
> > > > On Fri, Apr 12, 2019 at 2:40 PM <greearb@candelatech.com> wrote:
> > > >>
> > > >> From: Ben Greear <greearb@candelatech.com>
> > > >>
> > > >> This lets us more precisely calculate the absolute timestamp
> > > >> of last-rix (ie, now - idle).
> > > >
> > > > Can you use 64-bit timestamps? struct timeval suffers from the
> > > > overflow after 2038 problem.
> > >
> > > What is the preferred API to do this?  Whatever it is, it would need
> > > to compile on old crufty systems as well.
> >
> > I am not sure what the guidance for userspace is. The kernel uses
> > 'struct timespec64' I think.
> > Arnd (cc-ed) who has mostly led the 2038 problem in the kernel might
> > have more input on the
> > "old crufty systems" part.
>
> I'm not sure what you are trying to do, and there are different
> answers depending on the usecase.
>
> For getting the time in the kernel, see Documentation/core-api/timekeeping.rst
> do_gettimeofday() is going away for many reasons, so don't use that.
> It sounds like you want "ktime_to_ms(ktime_get())" here.
>
> In userspace interfaces, you should pass 64-bit nanoseconds as returned
> by ktime_get_ns().
>
> If you want to pretty-print the current wall-clock, use the %pt format string
> on a 'struct rtc_time'.

Ah, I see now this was just userspace code. In that case, using gettimeofday()
works fine, it will end up using a 64-bit version of 'timeval', and converting
that to 64-bit milliseconds is safe.

Using clock_gettime() is generally preferred over gettimeofday() since it
avoids the conversion from nanoseconds to microseconds (which you then
convert to milliseconds).

       Arnd