Re: [PATCH 1/2] core: add nm_utils_monotonic_timestamp_as_boottime() function

On Wed, 2015-04-29 at 10:48 -0500, Dan Williams wrote:
On Wed, 2015-04-29 at 08:02 +0200, Thomas Haller wrote:
On Tue, 2015-04-28 at 17:37 -0500, Dan Williams wrote:
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 <thaller 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.


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

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.


(did a further minor change to the API of libnm to have all types as
"gint", not "gint32". It was mixed before, and I decided for the former.

What do you think about 1.0.2 for this branch?

Hm, yeah... but it's new public API.
We didn't yet introduce any new API for 1.0.2 and it's kinda complicated
(as discussed here: )

I had local patches that added everything to the 1.0.2 section, but I
guess you merged the branch already.  I suppose if we backport to 1.0.4,
we could just move the symbols from 1.2 -> the 1.0.4 section before a
1.2 release?

Yes I merged the branch already to master... but that is no conflict.

Can you show your patches?

To my interpretation of bug 742993, we would backport it to linker
section libnm_1_0_[24], but we *also* must add it in those sections
on master... which requires some hacks...









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.

networkmanager-list mailing list
networkmanager-list gnome org

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]