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

Arnaud Quette aquette.dev at gmail.com
Wed Oct 3 13:49:11 UTC 2012


2012/10/3 <VaclavKrpec at eaton.com>

>   Hi Arnaud,****
>
> **
>

Hi Vaclav,


> 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)****
>
> ** **
>
> 2/ Having our own interface provides more flexibility****
>
> (The implementation may actually not be really straightforward)****
>
> ** **
>
> 3/ We don’t mind performance loss on wrappers****
>
> (Not that it would be that great)****
>
> ** **
>
> 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. ;-)
>

works for me, all-in to see ;)

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



> *From:* Arnaud Quette [mailto:aquette.dev at gmail.com]
> *Sent:* Wednesday, October 03, 2012 2:00 PM
> *To:* Krpec, Vaclav
> *Cc:* baruch at ev-en.org; nut-upsdev at lists.alioth.debian.org;
> clepple at gmail.com; baruch at debian.org
>
> *Subject:* Re: [Nut-upsdev] NUT Bugs #313634 & #313714: unification &
> encapsulation of timer proposition****
>
>  ** **
>
> ** **
>
> 2012/10/2 <VaclavKrpec at eaton.com>****
>
> Hello Baruch,****
>
>  ****
>
> thanks for your comment.****
>
> OK, I’ll just aim to create an implementation of all-purpose****
>
> portable clock with the possibility of monotonic/ real-time****
>
> operation (where available).****
>
> It still should be encapsulated, though.  Unlike time() and****
>
> difftime(), clock_*time() interface (or at least the monotonic****
>
> clock back-end) is not available everywhere.****
>
> If we want real portability, we need our own opaque type****
>
> and encapsulation of the implementation.****
>
>  ****
>
> I guess I’ll just code a proposition and we shall se...****
>
>
> another variation is to standardize on clock_gettime() / clockid_t, and to
> use AC_REPLACE_FUNC to provide it from NUT, if it's not avail. on the
> system.
>
> tell me back if you need some guidance to check this variation.
>
> 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****
>
>    *From:* Baruch Even [mailto:baruch at ev-en.org]
> *Sent:* Thursday, September 27, 2012 2:26 PM
> *To:* Krpec, Vaclav
> *Cc:* aquette.dev at gmail.com; nut-upsdev at lists.alioth.debian.org;
> clepple at gmail.com; baruch at debian.org
> *Subject:* Re: [Nut-upsdev] NUT Bugs #313634 & #313714: unification &
> encapsulation of timer proposition****
>
>  ****
>
> My opinion on this is that it might be a little too abstract. I'd go with
> what I essentially started which is to abstract just a monotonic clock with
> only what is needed. If the platform doesn't have a monitonic clock than it
> can be apprixmated.****
>
> This will also serve to explain the real intention of a monotonic clock
> and not just a plain timer.****
>
> My 2¢****
>
> Baruch****
>
> On Sep 27, 2012 1:19 PM, <VaclavKrpec at eaton.com> wrote:****
>
> Hello everybody,
>
> I'm working on the "Use difftime for time comparison" bug (#313634).
> Charles directed me to the other one "Use monotonic clock for monitoring"
> attended to by Baruch; I believe that's very good idea, however I'd use a
> bit
> more encapsulated & general approach:
>
> 1/ I'd create an opaque timer type and its get/set/cmp/inc/dec etc
> interface
> under common
> 2/ implementation of the interface would use the monotonic clock if
> available
> (the clock_*time on Linux, potentially other monotonic clock impl. on other
> systems) and time_t as a fallback
> 3/ when implemented, use of the timer shall be spread throughout the code,
> replacing direct use of time_t
>
> What do you think?
> I'm also a bit reluptant to do such a change in scope of the bugfix; I'd
> create
> a new feature req. for that, OK?
>
> Any comments/ suggestions welcome,
>
> Regards,
>
> Vaclav
>
> P.S: already managed to post this from another address by mistake, so
> please
> just discard the previous e-mail (or this one, depending on which you've
> read).
>
> --
> Václav Krpec
> Software Developer
> Network UPS Tools project
> Eaton Opensource Team
> Eaton European Innovation Center
>
>
>
>
> -----------------------------
> Eaton Elektrotechnika s.r.o. ~ S�dlo spolecnosti, jak je zaps�no v rejstr�ku:
> Kom�rovsk� 2406, Praha 9 - Horn� Pocernice, 193 00, Cesk� Republika ~ Jm�no,
> m�sto, kde byla spolecnost zaregistrov�na: Praha ~ Identifikacn� c�slo
> (ICO): 498 11 894
> -----------------------------
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev****
>
> ** **
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121003/c993d88b/attachment.html>


More information about the Nut-upsdev mailing list