On Tue, 2015-04-28 at 00:41 +0200, Thomas Haller wrote: > On Mon, 2015-04-27 at 16:31 -0500, Dan Williams wrote: > > On Wed, 2015-04-22 at 12:50 +0200, Thomas Haller wrote: > > > On Tue, 2015-04-21 at 12:47 -0500, Dan Williams wrote: > > > > On Tue, 2015-04-21 at 19:19 +0200, Thomas Haller wrote: > > > > > On Tue, 2015-04-21 at 19:04 +0200, Thomas Haller wrote: > > > > > > On Tue, 2015-04-21 at 11:48 -0400, Mathieu Trudel-Lapierre wrote: > > > > > > > From: Thomas Haller <thal...@redhat.com> > > > > > > > > > > > > > > > > > > I pushed both patches to upstream branch mtl/wifi-ap-last-seen for > > > > > > easier review. > > > > > > > > > > > > And I added two fixup commits with changes I that I suggest. > > > > > > > > > > > > > > > > > > Thomas > > > > > > > > > > > > > > > maybe it would be better to expose the timestamp as singed int in > > > > > libnm > > > > > so that we can signal "unseen" by setting -1. G_MAXUINT32 is not very > > > > > intuitive. > > > > > > > > I'd actually rather do '0' == unseen and keep it u32... > > > > > > why do you prefer that? > > > > > > '0' is a valid timestamp. IMO it should be overloaded with a > > > 'never-seen' meaning. > > > > Well, technically yes, but you will never, ever get that value because > > scan results will never happen that quickly :) I was going to write a > > paragraph about why I wanted it u32, but in this case it doesn't matter > > since the max last-seen value will never be > 240 or so. So sure, lets > > just make everything s32 and use -1 as the "never seen" value. > > > > I fixed this up and squashed the branch. Look OK? > > Pushed two fixups. With them it LGTM. > > > Note that with gint32, we still have a range of 68 years (uptime of the > system). No need to double that by using guint32.
Looks good. What do you think about 1.0.2 for this branch? Dan > Thomas > > > > > Dan > > > > > > > > Thomas > > > > > > > > > > > > > > > > > Dan > > > > > > > > > A gint32 is still large enough, unless you run your machine without > > > > > reboot for 68+ years. > > > > > > > > > > There isn't a Year 2038 problem, because the counter starts at last > > > > > boot, not in 1970. > > > > > > > > > > > > > > > Thomas > > > > > _______________________________________________ > > > > > networkmanager-list mailing list > > > > > networkmanager-list@gnome.org > > > > > https://mail.gnome.org/mailman/listinfo/networkmanager-list > > > > > > > > > > > > > > > > _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
