[Nut-upsdev] UPP schedule and progress

[VaclavKrpec at Eaton.com]

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>