search for: nut_clock_

2012/11/9 <VaclavKrpec at eaton.com> > Hello gentlemen, > Hi Vasek, I'm moving the thread to -upsdev, since it has not to be private... please note that revisions 3771 and 3772 conclude nut_clock_* > development (including UTs): > interestingly enough, we were talking about that 5 mn ago with Emilien ;) my conclusion was that nut_clock devs were completed with 3772, and only the QRT side was remaining. but that last requires: 1) that I provide you with a procedure to setup QRT (and th...

?Hello Arnaud, Charles, regarding the nut_clock_* iface unit testing, I came to the following conclusion: 1/ It is IMO generally impossible to do deterministic unit test; the problem in question is inherently non-deterministic (I mean non-det. by nature). Justification: the main reason is that we can't perfectly predict the CPU time spent on...

...ewhat misplaced in the configuration library, doesn't it? I'd rather encapsulate that to another library, which would become part of the NUT framework, either. I suggest libnutipc. Ext. commands execution (i.e. basis for driver inst. update): The core is already implemented at least in the nut_clock_* iface UT; it should be quite easy to make use of it. 2/ Sending signal to other process is a pretty simple task and with NutStream, we can read PIDs from .pid files on a couple lines of code... If it's implemented in libnutipc, we shall have to factorise libnutconf, though (extract nutstream)...