[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.
>  
To make my point a little clearer: I would suggest to implement this 
new, seperate ioctl. But it should not get announced in 
include/linux/dvb/frontend.h, instead your application should declare it 
locally on top of the file that uses it and the driver should silently 
implement it.

Holger