Hello everybody, so, here's the summary of my progress (note that it also includes a few items to discuss, so I'm cc-ing this to nut-upsdev as well). I. The planning: 1/ libnutconf: The core (i.e. config. classes and their (de)serialisers) is coded, UT in progress. Signalisation shall follow; I have a couple of practical thoughts & comments to this, see below. In general, I'd like to have libnutconf core UT-ed this week and the signal handling coded at the very least. This would mean that the last implementation point of the library (driver inst. update) would be completed during the 2nd. week of January (i.e. the 1st week I'm back from holiday). 2/ nutconf tool: The plan should hold (20 days if I'm not much mistaken); but please note another suggestion, below. 3/ nutcli tool: Emilien planned cca 20 days AFAIK; I think that should be feasible, mainly when considering the suggestion mentioned above; however, to make sure, I'd ask for another 5 days to have some slack... ;-) II. Some thoughts, recommendations etc: 1/ Signalisation & driver instance update modularisation: It seems somewhat 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). I suggest libnutio. 3/ Config. attribute access: As suggested for the nutconf tool, the access from command-line shall be done via attribute paths. E.g. upsd.users.upsmon.mode may be mapped to upsd.users::[upsmon]::upsmon directive value ("master"/"slave"). Note that this is just a proposition; what I wanted to show is the general approach. Now, I believe that this way of accessing NUT-related info is general enough that it may and should be available for other entities, too, not just for the nutconf tool; therefore, I suggest to create another library, let's say libnutattr. The config. paths would then begin with "config." prefix... And the nutconf tool may actually evolve into nutinfo tool (providing not only the configuration access, but maybe even replacing upsc by incorporating the run-time UPS attribute paths, too). I believe that using such attribute iface for nutcli implementation would also be quite beneficial (in both code simplicity and also to avoid duplicity in access implementation). III. Future considerations: 1/ Signal handling support in libnutipc (if agreed): I highly recommend to use sig. handling thread technique. That's because 1/ the amount of re-entrant functions is limited and 2/ the set may even vary on different platforms. If we'd like to do someething more complicated in reaction to a signal or even allow custom hooks etc, we simply can't do it in the sig. handler, safely. Therefore, the sig. handler should just pass the signal info to the signal handler thread (I suggest a pipe since pthread_cond_signal is problematic for async signals AFAIK (and it would also imply usage of pthreads, which we don't have, yet, right? With pipe, 512 B of data write is guaranteed, atomically (at least on Linux), which should be far enough, write re-entrancy being required by POSIX 2004, at least). I guess the mail is crammed with things enough already, so I won't add more... ;-) Regards, vasek ________________________________ 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 ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121210/87a82fe4/attachment.html>