<div dir="ltr"><div>Hello all,</div><div><br></div><div>  While working on possible solutions to the problem of monitoring identical-looking USB devices (which currently NUT treats as one matched device which is busy so goodbye), I wanted to separate handling of "busy" errors as fatal or optionally-no depending on whether the driver is being initialized vs. running in the regular loop.</div><div><br></div><div>  In the end, the solution for USB init landed elsewhere, but the driver-state tracking mechanism was made and tested, and can generally help in field troubleshooting (log reading, etc.) as well as queries with NUT clients (is driver stalled in updateinfo for too long?..)</div><div><br></div><div>  Since this feature also proposes to extend the schema of valid "nut-names", I bring it up for community discussion. Unless someone is strongly against it (including the choice of wording for the state names, though they are arguably "opaque strings" - but if someone would like to process them, it makes sense to set some standard/pattern too), I hope to merge this, say, after the weekend.<br></div><div><br></div><div>  See <a href="https://github.com/networkupstools/nut/pull/1771/files">https://github.com/networkupstools/nut/pull/1771/files</a> for the proposed changes, and <a href="https://github.com/networkupstools/nut/pull/1770">https://github.com/networkupstools/nut/pull/1770</a> for "screenshots" including those reports like</div><div><br></div><div>
<pre class="gmail-notranslate"><code class="gmail-notranslate">   0.000672     [D5] send_to_all: SETINFO driver.state "init.device"<br>   ...</code><code class="gmail-notranslate"><br>   0.425455     [D5] send_to_all: SETINFO driver.state "cleanup.exit"</code>

</pre></div><div></div><div>Jim Klimov<br></div><div><br></div></div>