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
