Adar Dembo has posted comments on this change. ( http://gerrit.cloudera.org:8080/15171 )
Change subject: [clock] ntp_gettime(): STA_NANO bites again ...................................................................... Patch Set 1: (1 comment) Would be nice to think about how we could test this. Seems hard without mocking the results of whatever "get time" system call we end up using. http://gerrit.cloudera.org:8080/#/c/15171/1//COMMIT_MSG Commit Message: http://gerrit.cloudera.org:8080/#/c/15171/1//COMMIT_MSG@9 PS1, Line 9: The issue fixed once in 10f6164b1217e0299bcfedc061d2c57581c389bd : was reintroduced again in e72208436. And this patch addresses it : once again. So here's ntp_gettime() implementation in glibc: int ntp_gettime (struct ntptimeval *ntv) { struct timex tntx; int result; tntx.modes = 0; result = __adjtimex (&tntx); ntv->time = tntx.time; ntv->maxerror = tntx.maxerror; ntv->esterror = tntx.esterror; return result; } And __adjtimex() is the adjtimex/ntp_adjtime system call. So the problem is that ntp_gettime() does not convert ntv->time using the presence of STA_NANO in tntx.status, right? How is that useful behavior? Seems like it makes the function completely unusable. Could you update the commit description with a bit more color as to what's actually going on? When I first looked at the patch I didn't understand _why_ we shouldn't use ntp_gettime() on Linux. -- To view, visit http://gerrit.cloudera.org:8080/15171 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: Id171b6fea2274d32a35c6173bab9996b36c0c4f6 Gerrit-Change-Number: 15171 Gerrit-PatchSet: 1 Gerrit-Owner: Alexey Serbin <[email protected]> Gerrit-Reviewer: Adar Dembo <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: Volodymyr Verovkin <[email protected]> Gerrit-Comment-Date: Thu, 06 Feb 2020 04:31:05 +0000 Gerrit-HasComments: Yes
