On Mon, Sep 22, 2014 at 5:21 PM, Thomas Haller <thal...@redhat.com> wrote:
[...]
>
> the value priv->last_seen (together with nm_access_point_get_last_seen()
> and nm_ap_set_last_seen()) are time stamps as returned by
> nm_utils_get_monotonic_timestamp_s().
>
> Exposing these absolute values (without a reference point) to another
> process is meaningless.

I disagree, maybe it's not meaningful to compare directly to boot
time; but it's sufficient to compare values between themselves to
figure out which networks are the newest.

That's currently what we're mostly interested in. I'm not sure if
there would be other use cases; but the idea is especially to provide
a way for applications to sort accesspoints by age and avoid using
those that have been in scan results before, but not necessarily old
enough or disappeared to be culled from the scan list just yet.

>
>
> Options:
>
>
> 1) expose the timestamps to absolute times in seconds since 1970 (posix
> time). Note that gint (with 32bit) is to short to represent that
> property.
>
> Downside: timestamps are all wrong in case of resetting the clock.

As a note, I actually ported this patch to NM master, but it really
has been tested on 0.9.8.8. I think we're at the point here where what
happens is that the timestamps on 0.9.8.8 are actually still retrieved
via time(NULL) initially, so this is basically what was achieved.


> 2) expose time stamps to clock_gettime(CLOCK_BOOTTIME) or
> clock_gettime(CLOCK_MONOTONIC).
>
> Downside: timestamps are only meaningful on the very same host. Its
> quite uncommon to expose DBUS over the network, but I think we don't
> want to restrict that.
>
> CLOCK_MONOTONIC is more commonly known then CLOCK_BOOTTIME, but has the
> additional downside of being wrong after hibernate.

FWIW, I vote for this solution (CLOCK_BOOTTIME specifically); it seems
an acceptable compromise that the values are only meaningful on the
host, since the list of accesspoints is also going to be only
meaningful on that host -- another might not see some, etc.

[...]

> Also note that priv->last_seen==0 means "never seen". Both for 1) and 2)
> above, 0 can represent a valid value.
>
> Arguably for 1), We could define that 0 (1970-01-01T00:00:00) means
> "never seen".
> But maybe it would be better to map "never seen" to -1 -- thinking of
> booting up a machine with drained CMOS battery that forgot the time
> stamp and starts ticking at posix-time 0.

With CLOCK_BOOTTIME, wouldn't 0 also be a value unlikely enough that
we can consider it "never seen"? Seems to me like even if
NetworkManager started at 0; it's quite unlikely that by the time the
system has gotten to start scanning it would still be at 0.


I'll update the patch shortly to fix at least Nathanael's comment re:
the wrong string; while we get to agree on exactly how the values
should display.

/ Matt
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Reply via email to