[linux-dvb] Re: refactoring

[Michael Hunold <hunold-ml@web.de>]

Hi,

On 06.10.2004 21:18, Andrew de Quincey wrote:
> If you keep going on this line of thought, you end up with:
>
> -----------
> struct dvb_frontend_api {
[...]
>         int (*fe_read_ber)(void* data, __u32 ber);
>         int (*fe_read_signal_strength)(void* data, __u16 strength);
>         int (*fe_read_snr)(void* data, __u16 snr);
>         int (*fe_read_ucblocks)(void* data, __u32 ucblocks);
Shouldn't we simply create a

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?

For V3 this doesn't matter because the ioctl will only deliver one value 
at a time. But V4 already has a similar kind of simplification and I'd 
like to keep the frontend stuff in sync.

Perhaps we can introduce a new ioctl that provides all informations to 
userspace at once.

>         int (*fe_diseqc_reset_overload)(void* data);
>         int (*fe_diseqc_send_master_cmd)(void* data, struct 
> dvb_diseqc_master_cmd* cmd);
>         int (*fe_diseqc_slave_reply)(void* data, struct 
> dvb_diseqc_slave_reply* reply);
>         int (*fe_diseqc_send_burst)(void* data, fe_sec_mini_cmd_t minicmd);
>         int (*fe_set_tone)(void* data, fe_sec_tone_mode_t tone);
>         int (*fe_get_voltage)(void* data, fe_sec_voltage_t voltage);
>         int (*fe_enable_high_lnb_voltage)(void* data, int arg);
>         int (*fe_dishnetwork_send_legacy_command)(void* data, unsigned int 
> cmd);
These are all DVB-S specific, so perhaps there should be a union with 
different functions depending on the type of the frontend? By this it 
would become clear non-DVB-S frontends don't have to mess with this.

CU
Michael.