[Nut-upsuser] suse linux and nut

[Arnaud Quette]

2006/8/30, Peter Selinger <selinger at mathstat.dal.ca>:
> 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.

not that heavy, though it would need a rework of the newhidups core.
But it would add more reliability to interrupt listening/handling,
since we currently can miss events due to the design weakness.

> 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.

interrupt data not being exposed in the report descriptor?!

> 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.

such units would so need to only depend upon interrupt?

> 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.

the threaded method would allow, with some sub-drv config, to launch
the polling thread and/or the interrupt thread. Either feeding the
core is not important since the core wouldn't care about that.

Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/