Arnaud Quette wrote: > > Hi > > 2006/8/27, Peter Selinger <[EMAIL PROTECTED]>: > > ... > > 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 _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
