[2/2] iw: Print current time in station info dump

Commit Message

Ben Greear April 12, 2019, 9:40 p.m. UTC

From: Ben Greear <[e-mail]>

This lets us more precisely calculate the absolute timestamp
of last-rix (ie, now - idle).

Signed-off-by: Ben Greear <[e-mail]>
---
 station.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Comments

Kirtika Ruchandani April 12, 2019, 9:43 p.m. UTC | #1

On Fri, Apr 12, 2019 at 2:40 PM <[e-mail]> wrote:
>
> From: Ben Greear <[e-mail]>
>
> 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.

>
> Signed-off-by: Ben Greear <[e-mail]>
> ---
>  station.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/station.c b/station.c
> index 3b0c5f1..60804f2 100644
> --- a/station.c
> +++ b/station.c
> @@ -314,6 +314,12 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
>                 [NL80211_STA_INFO_ACK_SIGNAL_AVG] = { .type = NLA_U8 },
>         };
>         char *chain;
> +       struct timeval now;
> +       unsigned long long now_ms;
> +
> +       gettimeofday(&now, NULL);
> +       now_ms = now.tv_sec * 1000;
> +       now_ms += (now.tv_usec / 1000);
>
>         nla_parse(tb, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
>                   genlmsg_attrlen(gnlh, 0), NULL);
> @@ -561,7 +567,7 @@ static int print_sta_handler(struct nl_msg *msg, void *arg)
>                 printf("\n\tauthenticated at:\t%llu ms",
>                          (unsigned long long)nla_get_u64(sinfo[NL80211_STA_INFO_AUTH_AT_MS]));
>
> -       printf("\n");
> +       printf("\n\tcurrent time:\t%llu ms\n", now_ms);
>         return NL_SKIP;
>  }
>
> --
> 2.7.5
>

Ben Greear April 12, 2019, 9:49 p.m. UTC | #2

On 4/12/19 2:43 PM, Kirtika Ruchandani wrote:
> On Fri, Apr 12, 2019 at 2:40 PM <[e-mail]> wrote:
>>
>> From: Ben Greear <[e-mail]>
>>
>> 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.

Thanks,
Ben

Kirtika Ruchandani April 12, 2019, 10:07 p.m. UTC | #3

On Fri, Apr 12, 2019 at 2:49 PM Ben Greear <[e-mail]> wrote:
>
> On 4/12/19 2:43 PM, Kirtika Ruchandani wrote:
> > On Fri, Apr 12, 2019 at 2:40 PM <[e-mail]> wrote:
> >>
> >> From: Ben Greear <[e-mail]>
> >>
> >> 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.


>
> Thanks,
> Ben
>
> --
> Ben Greear <[e-mail]>
> Candela Technologies Inc  http://www.candelatech.com
>

Arnd Bergmann April 13, 2019, 8 a.m. UTC | #4

On Sat, Apr 13, 2019 at 12:07 AM Kirtika Ruchandani <[e-mail]> wrote:
>
> On Fri, Apr 12, 2019 at 2:49 PM Ben Greear <[e-mail]> wrote:
> >
> > On 4/12/19 2:43 PM, Kirtika Ruchandani wrote:
> > > On Fri, Apr 12, 2019 at 2:40 PM <[e-mail]> wrote:
> > >>
> > >> From: Ben Greear <[e-mail]>
> > >>
> > >> 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'.

      Arnd

Arnd Bergmann April 13, 2019, 8:04 a.m. UTC | #5

On Sat, Apr 13, 2019 at 10:00 AM Arnd Bergmann <[e-mail]> wrote:
>
> On Sat, Apr 13, 2019 at 12:07 AM Kirtika Ruchandani <[e-mail]> wrote:
> >
> > On Fri, Apr 12, 2019 at 2:49 PM Ben Greear <[e-mail]> wrote:
> > >
> > > On 4/12/19 2:43 PM, Kirtika Ruchandani wrote:
> > > > On Fri, Apr 12, 2019 at 2:40 PM <[e-mail]> wrote:
> > > >>
> > > >> From: Ben Greear <[e-mail]>
> > > >>
> > > >> 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

Patch

diff --git a/station.c b/station.c
index 3b0c5f1..60804f2 100644
--- a/station.c
+++ b/station.c
@@ -314,6 +314,12 @@  static int print_sta_handler(struct nl_msg *msg, void *arg)
 		[NL80211_STA_INFO_ACK_SIGNAL_AVG] = { .type = NLA_U8 },
 	};
 	char *chain;
+	struct timeval now;
+	unsigned long long now_ms;
+
+	gettimeofday(&now, NULL);
+	now_ms = now.tv_sec * 1000;
+	now_ms += (now.tv_usec / 1000);
 
 	nla_parse(tb, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
 		  genlmsg_attrlen(gnlh, 0), NULL);
@@ -561,7 +567,7 @@  static int print_sta_handler(struct nl_msg *msg, void *arg)
 		printf("\n\tauthenticated at:\t%llu ms",
 			 (unsigned long long)nla_get_u64(sinfo[NL80211_STA_INFO_AUTH_AT_MS]));
 
-	printf("\n");
+	printf("\n\tcurrent time:\t%llu ms\n", now_ms);
 	return NL_SKIP;
 }