Completely agreed, That's why I proposed to consider struct bintime.
We can tackle various aspects of improving the implementations
benefiting from the improved APIs at any time later.
IMHO struct bintime is sufficiently powerful enough to cover the
interface stability requirements (nsec are already being split
by 4 with 4+GHz cycle counters - so something better than timespec
should already be in scope).
Frank
On 01/04/17 22:55, Robert Elz wrote:
Date: Wed, 04 Jan 2017 22:06:35 +0100
From: Frank Kardel <[email protected]>
Message-ID: <[email protected]>
| The extendend resolution would be done providing the API.
IMO, what is important right now, is that when designing new APIs
(which is what Paul is doing) (and or changing old ones) we get that
design right, so it doesn't need to change again in the future, with
all the consqquest vessioning required to keep things working.
Whether or not the data provided through the "really good" API is as
good as it could be is a far less important issue - that can be improved
(fairly unobtrusively) whenever someone has the time to work on it.
kre
