On Sun, 17 Feb 2008 23:29:36 +0300, Carlos Rodrigues <[EMAIL PROTECTED]> wrote:
> On Feb 17, 2008 7:56 PM, Alexander I. Gordeev <[EMAIL PROTECTED]> wrote: >> > The best solution would probably to ignore the first couple of failures in >> > the 'megatec.c' driver, before declaring data stale. Generally speaking, >> > one should be careful to declare data stale and only do so after a couple >> > of attempts to read the status (typically three in a row) have failed. >> >> I like the idea of solving this in megatec.c. Both serial and usb >> interfaces could easily fail. > > If the driver fails to get any data in the current polling cycle, it > declares the data as stale until the next cycle. It tried to read the > data, it got nothing, ergo the current data is stale. I don't agree > the driver should systematically retry reading the status within a > polling cycle. > > However, if communication failures are a systematic problem over USB, > the USB layer should deal with it appropriately. > Still I concern about the added latency. I can retry after timeout but it means that ser_send_pace will not return for seconds. I'd rather add a variable in megatec.c to make user decide the number of retries before driver declares data stale (0 by default). -- Alexander _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser