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

[Holger Waechtler <holger@qanu.de>]

Johannes Stezenbach wrote:

> Ralph Metzler wrote:
>  
> > Johannes Stezenbach writes:
> > > The whole issue could be trivially fixed by converting cinergyT2
> > > to use the dvb_frontend core, as *all* other frontends do.
> > > I would volunteer to do that, however I won't unless Holger
> > > gives me an OK -- I guess he had some reasons not to use
> > > dvb_frontend.
> >
> > I don't know his reasons but for some frontends you just do 
> > not need/want the whole dvb_frontend stuff, especially if it 
> > is changing every few weeks.
> >    
> It isn't changing every few weeks. It changed once during
> restructuring. (Unless you count the intermediate restructure
> attempts, but you didn't have to follow those.)
>
>  
> > I am also not using it for Twinhan cards myself.
> >    
> Why? It won't be more code to use dvb_frontend.
>  
it would.

> So, what's the problem?
>  
all the workarounds are easily interfering with properly designed 
hardware that does everything just right, do you remember all the 
requests to allow to disable zigzag-scan, recovery code etc?

The less code your driver depends on the more robust it will be. 
Especially the frontend thread code has been well-known in the past to 
be sensible to changes that silently break one driver while fixing 
another one.

> > Maybe dvb_frontend should just export some message queue handling
> > calls. 
> >    
> It is unnecessary. See above.
>  
it is not -- library-alike code is always more flexible usable.

> > Regardless of all this, an application should handle getting an
> > EINVAL or ENOTSUPP from FE_GET_EVENT.
> >    
> The API (as documented) requires frontends to implement FE_GET_EVENT.
> Why should we want to break this?
>  
is somewhere stated that this ioctl is mandantory, I can't remind so? As 
for all other ioctls the application has to check the return value and 
properly handle this.

Holger