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