[Nut-upsuser] suse linux and nut

Peter Selinger selinger at mathstat.dal.ca
Wed Aug 30 13:34:50 UTC 2006


Arnaud Quette wrote:
> 
> Hi
> 
> 2006/8/27, Peter Selinger <selinger at mathstat.dal.ca>:
> > ...
> > What's to do here for the NUT developers is: first, improve support
> > for interrupt transfers in newhidups.
> 
> right, as we still rely on the (very) early code I first wrote.
> moreover, the big nested "if" in update is not clean and too heavy.
> lastly, I'm thinking for some time about adding threading support,
> which ie means in our case that we could have an interrupt dedicated
> thread + a polling thread, both feeding the main thread with HID
> objects. The main thread would then decode these and call
> dstate_setinfo()...

This is not what I had in mind. I think that threading is too
complicated and heavy for such a simple task.

The main problem with interrupt transfers at the moment is that
NUT somehow ignores all the variables that are not found during the
first run of dstate_setinfo(). Interrupt variables are not discovered
during this first run, and are therefore ignored. I am not sure at the
moment what causes this.

Another, minor problem with interrupt transfers is that there exist
buggy UPSs (my Belkin UNV in particular), which allow the same
variable to be polled by interrupt and regular transfers, and give a
*different* result depending on the method! Unfortunately, this
happens for an important flag such as the "on battery" flag.

I have started, some time ago, to improve the interrupt handling in
the "reportbuf" branch. The main reason I haven't merged this code
back into the trunk is that I first need to find a case-by-case
workaround to deal with buggy UPSs such as the Belkin. 

-- Peter




More information about the Nut-upsuser mailing list