[Nut-upsdev] NUT Bugs #313634 & #313714: unification & encapsulation of timer proposition

[Arnaud Quette]

Hi Charles

2012/10/3 Charles Lepple <clepple at gmail.com>

> On Oct 3, 2012, at 8:41 AM, <VaclavKrpec at Eaton.com> 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().
>

true, HPUX 11.31/ia64 does provide clock_gettime(), but not the the
MONOTONIC clockid_t.
for now, I've no solution / conclusion on that last part.
Missing clock_gettime() can be addressed through AC_REPLACE_FUNC...

> 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.
>

since Vaclav is still in the "new member integration pipe", as told in my
previous mail, I'd like to see a first patch going out.
This will allow to do an actual code review (and not an idea review) and to
force some buildbots tests to check the general compilation behavior.

but my general stance is still the same as Charles (KISS + focus on what is
really needed).
Now, I'm not that available currently, and I like to see some actual code
from Vaclav...

cheers,
Arnaud
-- 
Linux / Unix / Opensource Engineering Expert - Eaton -
http://opensource.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121003/ea978a4f/attachment.html>