Hello Roberto<br><br><div><span class="gmail_quote">On 7/26/06, <b class="gmail_sendername">Arnaud Quette</b> <<a href="mailto:aquette.dev@gmail.com">aquette.dev@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Hi Roberto,<br><br>please keep the list cc'ed has the below things can be interesting to others...<br><br><div><span class="gmail_quote">2006/7/25, Roberto - Engenharia - Microsol <<a href="mailto:roberto@microsol.com.br" title="mailto:roberto@microsol.com.br" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
roberto@microsol.com.br</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Arnaud.<br><br>My question was just to know if had some another suggestion beyond creating
<br>a new file at conf/ dir to store "last test date". Just to listen<br>suggestions, no more. ;-)</blockquote><div><br>ok, I wasn't sure.<br>for the moment, there is no internal mechanism to allow data persistance.
<br>But there is a sub project underway to deal with configuration files (formalism and accessors, check there: <a href="http://opensource.mgeups.com/projects/nut-config.htm" title="http://opensource.mgeups.com/projects/nut-config.htm" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://opensource.mgeups.com/projects/nut-config.htm
</a>). And part of this is the variables settings in config files (<a href="https://alioth.debian.org/pm/?group_id=30602" title="https://alioth.debian.org/pm/?group_id=30602" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://alioth.debian.org/pm/?group_id=30602</a>).<br>That answers to 1 point of your need: retrieving a driver parameter at driver init.
<br>But not yet to the "store this data somewhere"... Though the best place is to store it in the driver's subjection, ie in ups.conf:<br>[myups]<br>...<br>battsched = ...<br><br>For the moment, there are access rights problems that avoid driver to write in the config files.
<br><br>@Jonathan: do you have an idea to address this?</div></div></div></blockquote><div><br>Yes, I have. <br>The new configuration format I'm working on will easilly enable to do this. The unified tree for data and config has a notion of access rights, as you said. One of this rights is all_rw, that is to say that all nut user can read and write it.
<br><br>As I see it, you'll have to add the battsched value in the configuration file with this right (manually or via libupsconfig)(because simple nut user don't have the rights to add value in the tree) and then a client would be able to ask upsd to modify the battsched value (nammed something like
nut.ups.myups.battery.sched I think). upsd will modify the value, and will answer any request about its value. If you make another test, just ask upsd to write the new value in this variable<br><br>When upsd will shutdown, it will save the configuration part of the tree in the configuration files, including this value, so when upsd will restart, the good value will be restored, inssuring its remaining.
<br><br>For the moment, upsd don't have this unified tree and what I said is impossible. You need to insure yourself the remaining of such a data. But it will become possible as soon as the new upsd, using the unified tree, is developed.
<br><br>I'm writing a file text exposing all my ideas about the subject, and about security issues it imply and so on. I'll put it on the list as soon as I finish it.</div></div><br>NUT project is improving, new functionnalities will be available. Just let it a little time.
<br><br>8<------ sniping the last part.<br><br>Cheer, <br><br>Jonathan Dion<br>