[linux-dvb] Re: cinergyT2: which kernel/usb module to use?

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Holger Waechtler wrote:

> ...
> The entire idea of caching pasttime events in a ringbuffer was bogus, do 
> you know any use for this? Your code contains a race condition that can 
> show up at particular combinations of CPU speed and status update rates. 
> Maybe only a theoretical one but in any case an example for bad 
> programming.
>
>
> > > The correct implementation is this:
> > >
> > >       while (!exit) {
> > >               select(fd, ...);
> > >               ioctl(fd, FE_READ_STATUS, &status);
> > >               /* process/display status */
> > >       };
> > >   
> >
> > Select what? If the driver sees an event so it can wake up poll(),
> > it surely can generate a frontend event, no?
> > Certainly it is valid to call FE_READ_STATUS instead of looking
> > at the event retrieved with FE_GET_EVENT, but the API guarantees
> > that FE_GET_EVENT will also give you the tuning status.
> >  
> a pasttime event, yes. But who cares about the lockbit status some while 
> ago?
>
> Holger
Back when I did some experimenting in that area it looked as if
FE_READ_STATUS would return an FE_HAS_LOCK _immediately_ after tuning (presumably
the status bits were still at the value they had vefore tuning),
although the lock clearly wasn't there yet. Also, checking with FE_READ_STATUS
periodically indicated that every now and then the lock was _lost_, although
the signal was displayed load and clear. The FE_GET_EVENT way appeared
to be much more stable and reliable.

From an application programmer's view it really would be great if the driver
gurus could agree on a reference implementation of how exactly tuning
and waiting for a lock is supposed to be done...

Klaus