On Tue, May 16, 2006, Manu Abraham wrote:
> Updated the patch again
The main problem I see is that you still try to cram
too much into the DVB-S2 API.
Adding stuff which might be missing is easy.
Removing stuff which might turn out to be wrong is
just *not possible* without destroying both source
and binary compatibility.
That's why plead again to remove everything which
isn't necessary for receiving the DVB-S2 transmissions
in use today.
> +enum dvbfe_modulation {
> + DVBFE_MOD_IGNORE = (0 << 0),
> + DVBFE_MOD_UNKNOWN = (1 << 0),
Both IGNORE and UNKNOWN?
test_api.c doesn't use IGNORE, nor is it documented in frontend.h.
Maybe you just forgot to remove them IGNOREs?
> + DVBFE_MOD_AUTO = (1 << 30),
> + DVBFE_MOD_DUMMY = (1 << 31)
As per my other mail, DUMMY is not neccessary here.
> + * Frontend Inversion (I/Q Swap)
> + */
> +enum dvbfe_iqswap {
Why this gratuitiuos rename? What's wrong with "inversion"?
> +struct dvbfe_dvbs_info {
> +struct dvbfe_dss_info {
> +struct dvbfe_dvbc_info {
> +struct dvbfe_dvbt_info {
> +struct dvbfe_dvbh_info {
All this I don't believe are useful. If someone writing
an application can plausibly explain to me how they
would be used, then OK. Until then I vote for leaving them
out of the API. We managed without them quite good so far.
> +struct dvbfe_dvbs2_info {
This one, maybe, in the future, when we know what the
different capabilities of DVB-S2 frontends actually are.
> +/*
> + * ATSC capability bitfields
> + */
> +struct dvbfe_atsc_info {
> + enum dvbfe_modulation modulation;
> +
> + __u8 pad[32];
> +};
And this might better be ATSC-C vs. ATSC-T?
I've no idea, but yes some kind of way to distinguish
different ATSC delivery systems is necessary.
Or do ATSC people actually prefer it that way?
> +struct dvbfe_caps {
> + union {
> + struct dvbfe_dvbs_info dvbs;
...
> +struct dvbfe_info {
This mixture of "caps" and "info" is suboptimal.
Johannes
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
