On Oct 3, 2012, at 8:41 AM, <[email protected]> wrote: > I see, however I think that it’s actually better to do the encapsulation. > Justification: > > 1/ We need to alter widespread code, anyway > (I mean if we used clock_gettime already and just needed to implement it > for platforms that don’t have it, using the autoconf macro would be nice > and fast way to do it, but since we don’t, well, see point 2 and 3)
It would be nice if we could use the autoconf macro, but the problem is that we are not guaranteed to have the monotonic clock type just because we have clock_gettime(). > But of course, I can just implement clock_gettime; however, I already have > the new module written, so I’d rather continue in this direction, if you don’t > insist on it... > Note that I’m still on my branch so no harm done. ;-) Your original timer abstraction sounded like it might need a lot of test code to go along with it. Please keep it simple, only implementing the interfaces that are necessary for now. I don't recall the state of unit test code in the NUT tree (there was a branch at one point), but this might be hard to debug if we don't have some simple test harnesses. After all, rolling the clock back (which is my understanding of what the monotonic clock interface guards against) is usually a privileged operation. Since you're working for Eaton, Arnaud has the final word here, but speaking as someone who plans to review the code, this sounds to me like it is getting overly complicated. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
