[linux-dvb] Re: Can the auto symbol rate patch for mt312 be merged?

[Holger Waechtler <holger@qanu.de>]

Roberto Ragusa wrote:

> On Mon, 06 Sep 2004 11:33:39 +0200
> Holger Waechtler <holger@qanu.de> wrote:
>
>
>  
> > Just go on and add your code, as long no other hardware supports these 
> > capabilities a "private" API should be ok. Please don't add your ioctls 
> > in the linux/include/frontend.h file but keep them private in a include 
> > file shared between mt312.c and your userspace scan application, as soon 
> > we have a fixed API both would need to get touched again anyways. For 
> > now they are too specific tied to the mt312.
> >    
> I don't think I've understood what you mean.
> As my first goal is to avoid the need to recompile the kernel to have
> blindscan capability and as some kernel support is required to do this, it
> is necessary to at least have an undocumented kernel feature (e.g. the
> mt312 frontend accepts strange symbol rate values, which should be normally
> rejected); which I dislike, as it's not an acceptable behaviour from my
> point of view, expecially in free software.
>
> So the choice is between:
> - having a minimally invasive, hacked, somewhat documented feature for mt312
> only (my first idea: sending the range bitmask as symbol rate)
> - creating a modest API extension, ready for adoption by other frontends
> and well documented as a feature which could be available or not
> (FE_HAS_AUTO_SYMBOL_RATE) (my second idea: introducing an ioctl to set
> the range before tuning)
>
> Are you saying that even the 2nd choice is too invasive for you?
> The patch is really small and clean, just a new ioctl which passes a
> struct containing two integers.
>  
Right now I'd vote for option (1), on the long term I would propose the 
API I suggested in a previous mail, we implemented this for a different 
(non-linux) project for the MT352 and it works just fine. Due to it's 
generality it may suit other hardware much better than the more 
low-level approach you implemented for the MT312 (and I assume it should 
be also possible to implement this for the '312 -- the Zarlink Eval 
Software provides exactly this functionality in it's API).

As intermediate step the approach (1) should be just perfect -- but I 
would like to avoid such extensions in the public API until it is clear 
that the approach is generic enough to be implemented in different 
flavors of hardware.

Holger