On 07/01/2015 22:30, Paul Jarc wrote:
> Ok. And then in the other direction, use sysclock_from_tai() and
> subtract TAI_MAGIC?
Yes, exactly.
> Without knowing the application's requirements, successfully hiding
> the system clock means you would have to supply *all* the interfaces
> that work with time values: *stat(), utimes(), localtime(), mktime(),
> etc., not just time(). But it seems like it would be less work to
> just supply the conversion functions, and let the application convert
> from/to whatever data source it uses.
Yes, it's true. So far I had only needed gettimeofday, settimeofday
and localtime, and hadn't thought of the stat family, that needs
system-clock timestamps, so I was happy with the current state. But
you're right and conversion functions are necessary.
> I don't mind writing it myself. Would you like a patch or git pull
> request?
Oh, I prefer having full control over the source :)
I'll gladly take suggestions for the naming scheme, however: as you
may have noticed, I'm not very good at naming, and the tai_from_*
namespace is starting to get a bit crowded with two slightly
different meanings. So if you can come up with something consistent
and not exceedingly inconvenient, I'll take it.
> I'm writing code that other people should be able to use, and I don't
> want to put constraints on how they configure skalibs. I just want to
> use the tai functions, including tain_now(), in a way that will work
> for any self-consistent set of skalibs configuration options that
> someone else may have set. Do I need tain_init() for that? If not,
> then it sounds like it may not need to be part of the documented API.
tain_init() doesn't hurt at all. It's just not needed.
I should probably remove it.
--
Laurent
Received on Wed Jan 07 2015 - 22:18:53 UTC