Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: refactoring



On Friday 08 Oct 2004 09:41, Gerd Knorr wrote:
> Andrew de Quincey <adq_dvb@lidskialf.net> writes:
> > > struct dvb_fe_status {
> > >  __u16 flags;
> > >  __u32 ber;
> > >  __u16 strength;
> > >  __u16 snr;
> > >  __u32 ucblocks;
> > >  __u32 reserved[4];
> > > };
> > >
> > > #define DVB_FE_BER_VALID 0x1
> > > #define DVB_FE_STRENGTH_VALID 0x2
> > > #define DVB_FE_SNR_VALID 0x4
> > > #define DVB_FE_UCBLOCKS_VALID 0x8
> > >
> > > and only provide one function to query these informations?
> >
> > Yeah that would be nicer.
>
> When hiding the ioctl API details and thus we don't have to touch the
> fe drivers when switching from v3 to v4 (or add v4?) it makes more
> sense to have a nice function pointer interface .
>
> > I was also thinking of a general "settings" IOCTL to initially setup the
> > frontend... e.g. for FE_ENABLE_HIGH_LNB_VOLTAGE.
>
> Hmm, why?  The device initialization (i.e. attach_<fe> function)
> should do the initial setup as well I think.  Or do you need some way
> to kick the fe in the ass to bring it back online after some
> mysterious failure?

It was for things like the HIGH_VOLTAGE thing - that (I assume) is supposed to 
be specified by userspace, so it can't go in the attach_<fe> function. I was 
meaning if there were other things like that we could think of...




Home | Main Index | Thread Index